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DETAILED  DESIGN  SPECIFICATION  FOR  PRODUCT  THREE-SIGNIFICAN1 

SOLDIER  CHARACTERISTICS 


1.0  SCOPE 

The  goa!  of  MANPRINT  Product  3  is  to  conceive,  design  and  implement  a 
software  system  to  assist  Army  human  factors  specialists  in  the  specification 
of  soldier  characteristics  of  importance  to  weapon  and  support  system 
hardware  designers.  Product  3  shall  have  the  capability  of  leading  a  human 
factors  specialist  to  pertinent  characteristics  based  on  a  taxonomic 
description  of  the  system  being  specified.  The  proposed  software  system 
shall  also  have  a  number  of  features  designed  to  improve  its  usefulness, 
including  the  ability  to:  (1 )  save,  edit,  and  print  every  screen  display  in  the 
design  search  process,  (2)  perform  user-defined  analyses  and  evaluations 
of  data,  3)  intelligently  modify  and  add  to  the  data  bases,  either  from  the 
keyboard  or  from  mass  storage  devices,  and  (4)  access  extensive  on-line 
help  and  tutorial  facilities.  Such  features,  along  with  the  basic  functionality, 
enable  Product  3  to  permit  easy  but  comprehensive  design  searches  by 
professionals  not  trained  in  computers. 

This  specification  covers  the  top  level  and  detailed  software  structure  of  a 
proposed  MANPRINT  Product  3.  It  includes  both  general  and  detailed 
software  design  requirements  for  the  development  of  the  proposed  system. 
The  design  is  based  on  the  concept  paper  submitted  in  response  to  Phase  I 
of  the  MANPRINT  program.  The  top  level  software  components  are  as 
follows:  the  design  aid  interface  component,  the  search  process  record 
component,  the  analysis  component,  the  knowledge  acquisition  interface 
component,  the  training/help  component,  the  alphanumeric  data  base 
component,  and  the  graphics  data  base  component.  These  components 
constitute  the  entirety  of  the  MANPRINT  Produce  3  software  system.  The 
hardware  and  requirements  are  as  defined  in  the  integration  rules  provided 
by  the  Army  Research  Institute.as  referenced  in  Appendix  I,  System 
Integration  Guidelines.  The  software  language  requirements  are  in 
accordance  with  guidance  from  the  Army  Research  Institute,  as  referenced 
and  expanded  upon  in  Appendix  II,  Language  Specification.  This  document 
is  intended  to  be  used  in  the  development  of  the  MANPRINT  Product  3 
software  system  during  Phase  3  of  the  contract. 

In  addition  to  the  primary  authors  listed  for  this  specification,  substantial 
assistance  was  rendered  by  the  following  American  Institutes  for  Research 
personnel:  Lauress  L  Wise  and  David  L  Winter  in  the  area  of  data  file 
identification  and  specification;  Donald  H.  McLaughlin  in  the  design  of  the 
overall  software  architecture;  and  Mildred  Jarvis  and  David  S.  Dow  in  the 
organization  and  preparation  of  the  final  report. 
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2.0  APPLICABLE  DOCUMENTS 


The  following  documents,  of  the  exact  edition  shown,  form  a  part  of  this 
specification  to  the  extent  specified  herein.  In  the  event  of  conflict  between  the 
documents  referenced  herein  and  the  contents  of  this  specification,  the 
contents  of  this  specification  shall  be  considered  a  superseding  requirement, 
in  this  specification  references  to  paragraphs  of  this  specification  and  of 
applicable  documents  invoke  all  subparagraphs  except  where  specific 
subparagraphs  are  excluded. 

2.1  Government  Documents 

2.1.1  Standards 

MIL-STD-1472C 
2  May  1981 
Notice  1 

1  September  1983 
Notice  2 
10  May  1984 
Notice  3 
17  March  1987 


2.1.2  Regulations 

APR  161-35  Hazardous  Noise  Exposure 

9  April  1982 


2.1.3  Handbooks 

MIL-HDBK-759  Human  Factors  Engineering  Design 

30  June  1981  for  Army  Material 

AFSC  DH  1-3  Human  Factors  Engineering 

1  December  1982 

AFSC  DH  2-8  Life  Support 

14  October  1983 


Human  Engineering  Design  Criteria 
for  Military  Systems,  Equipment  and 
Facilities 
Section  5.15 
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2.1.4  Other  Documents 


ESD-TR-86-278  Guidelines  for  Designing  User  Interface 

August  1986  Software 

AFAMRL-TR-85-013  Person  Computer  Dialogue:  A  Human 

January  1985  Engineering  Data  Base  Supplement 


2.1.5  Texts  and  Journals 


Boff,  K.;  Kaufman  L.; 

Thomas,  J. 

Handbook  of  Perception  and  Human 
Performance 

Dumas,  J. 

1987 

Designing  User  Inerfaces  for  Software 

Fraser,  L. 

1966 

The  Effects  of  Confinement  as  a  Factor 
in  Manned  Space  Flight  (NASA  -CR-51 1 ) 

Jor.cs,  F;  Prince,  A. 

1964 

Man’s  Function  in  Military  Space  Systems 
(McDonnell  Douglas  Report  A-507) 

Parker,  J;  West,  V. 

1973 

Bioastronautics  Data  Book 
(NASA-SP-3006) 

Schowalter,  D.;  Malone,  J. 
1972 

The  Development  of  a  Lunar  Habitability 
System  (NASA-CP-1 767) 

Woodson,  W. 

1981 

Human  Factors  Design  Handbook 

3.0  DESIGN  REQUIREMENTS 

3.1  Top  Level  Design  Requirements 

3.1.1  Software  Architecture 

The  software  components  listed  below  shall  constitute  the  entirety  of  the 
MANPRINT  Product  3  software  system  and  shall  provide  the  capability  to 
interact  with  the  hardware  requirements  as  defined  in  Appendix  I,  provided  by 
the  Product  Integration  Rules,  Army  Research  Institute,  31  July  1987.  Figure 
3-1  provides  a  diagram  of  the  components  showing  the  relationship  of  the 
components  to  one  another.  The  seven  top  level  software  components  shall 
be: 

a.  Design  Aid  Interface  Component 

b.  Search  Process  Record  Component 

c.  Analysis  Component 

d.  Knowledge  Acquisition  Interface  Component 

e.  Training/Help  Component 

f.  Alphanumeric  Data  Base  Component 

g.  Graphics  Data  Base  Component 


3.1. 1.1  Design  Aid  Interface  Component 

The  Design  Aid  Interface  top  level  software  component  shall  provide  the 
capability  to  access  system  information  and  utilities,  guide  the  user  through  a 
design  aid  session,  and  control  access  and  data  flow  to  all  other  top  level 
software  components.  The  Design  Aid  Interface  component  shall  function  as 
the  primary  user-system  interface.  Logging  on  shall  bring  the  user  directly 
into  the  Design  Aid  Interface  component.  The  Design  Aid  Interface  shall 
automatically  display,  upon  system  initialization,  the  top  level  menu,  from 
which  the  user  may  select  access  to  system  functions.  At  a  minimum,  the 
Design  Aid  Interface  Component  shall  provide  the  capability  to: 

a.  Access  and  retrieve  all  alphanumeric  and/or  graphic  information 
available  on  the  soldier  characteristics  that  affect  the  design  of  the 
system  under  consideration. 

b.  Access  a  sample  design  aid  session. 

c.  Obtain  on-line  help  information  to  assist  in  the  design  search 
process. 
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Knowledge 

Acquisition 


Functional  Diagram 


<±  Add,  delete,  or  modify  existing  soldier  characteristic  alphanumeric 
data  files. 

e.  Add  or  delete  bit-mapped  soldier  characteristic  graphic  files. 

f.  Access  existing  analysis  routines. 


3.1 .1.2  Search  Process  Record  Component 

The  Search  Process  Record  top  level  software  component  shall  automatically 
retrieve  and  store  copies  of  soldier  characteristics  alphanumeric  and  graphic 
data  base  materials  accessed  by  a  user  during  a  design  aid  session, 
including  all  input  and  output  screen  displays  associated  with  the  retrieval 
process.  The  Search  Process  Record  shall  provide  the  capability  for  the  user 
to: 

a.  Access  all  design  aid  session-specific  data  any  time  during  the 
design  aid  session  for  review  and/or  editing. 

b.  Provide  the  user  the  option  to  save  design  aid  session  outputs  to 
the  system  hard  disk  or  on  a  floppy  disk,  as  desired. 

c.  Recall  design  aid  session  data- and  screens  at  a  future  time  for 
review  and/or  editing. 

3.1.1 .3  Analysis  Component 

The  Analysis  top  level  software  component  shall  maintain  and  control 
Product  3  analytic  routines  as  required  to  support  user-initiated 
transformation  and  manipulation  of  information  contained  in  the 
Alphanumeric  Data  Base  component.  The  Analysis  component  shall  have 
the  capability  to  call  for  and  apply  individual  statistical  operations  to 
designated  data  base  files.  As  a  minimum,  the  following  parametric  and 
nonparametric  statistical  operations  shall  be  provided: 

a.  Descriptive  statistics. 

b.  Parametric  and  nonparametric  correlations  (Pearson  and 
Spearman). 

c.  Transformations  (linear  and  nonlinear  algebraic). 

d.  Time  series  (moving  average  and  autoregressive-moving  average 
(ARIMA)). 
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3.1 .1.4  Knowledge  Acquisition  interface  Component 

% 

The  Knowledge  Acquisition  Interface  top  level  software  component  shall 
provide  the  functional  capability  to  update  the  Product  3  alphanumeric  and 
graphics  data  bases.  There  shall  be  two  modes  of  data  entry:  manual  and 
automatic.  The  manual  mode  shall  provide  the  capability  to  add  new 
alphanumeric  data  files,  modify,  and/or  delete  existing  data  files  directly  from 
the  workstation  keyboard.  The  automatic  mode  shall  provide  the  capability  to 
update  Alphanumeric/Graphic  data  files  via  compatible  floppy  disks  and/or 
Bernoulli  removable  disks. 

3.1 .1.5  Training/Help  Component 

The  Training/Help  top  level  software  component  shall  provide  the  functional 
capability  for  users  to  obtain  assistance  in  two  areas: 

a.  Training 

The  training  function  shall  provide  the  capability  for  the  user  to: 

(1)  access  and  view  a  sample  design  aid  session,  with  no 
technical  inputs  required  from  the  user. 

(2)  access  and  view  a  demonstration  of  all  functions  of  the  system 
to  provide  the  user  with  an  understanding  of  the  functionality 
of  the  system  and  to  obtain  a  cognitive  model  of  the  system 
operation. 

b.  Help 

The  help  function  shall  be  integrated  with  and  encompass  all 
Product  3  user-system  interface  operational  and  maintenance 
activities,  including  but  not  limited  to  those  associated  with  the 
Design  Aid  Interface,  Search  Process  Record,  Analysis,  and 
Knowledge  Acquisition  Interface  components.  Help  prompts  and/or 
access  to  the  help  functions  shall  be  an  integral  element  of  all 
display  screens.  Prompts  shall  be  designed  to  assist  the  user  in 
determining  the  function  of  and  inputs  required  for  system 
operational  and  maintenance  activities.  Help  screens  shall 
describe  the  present  location  in  the  search  process  and  briefly 
outline  the  legal  paths  available  to  the  user.  All  help  and  prompt 
text  shall  be  in  plain  English  and  easily  understood  by  the  user, 
without  need  for  translation.  In  addition,  a  glossary  of  terms  used 
throughout  the  MAN  PRINT  programs  shall  be  available  to  the  user. 

3.1 .1.6  Alphanumeric  Data  Base  Component 

The  Alphanumeric  Data  Base  top  level  software  component  function  shall  be 
to  store  and  control  all  information  on  soldier  characteristics  available  to  the 
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system,  with  the  exception  of  the  terminal  graphics  displays  as  defined  in  the 
Graphics  Data  Base  component.  This  information  shall  be  maintained  in 
formatted  or  unformatted  text  files  on  the  hardware  system's  mass  storage 
devices  as  defined  in  the  hardware  integration  requirements.  This 
component  shall  not  be  directly  accessible  to  the  user;  however,  the  user 
shall  have  indirect  access  to  all  information  contained  in  the  data  base 
through  the  Design  Aid  Interface,  Analysis,  Search  Process  Record,  or 
Knowledge  Acquisition  Interface  components. 

3.1.1.7  Graphics  Data  Base  Component 

The  top  level  Graphics  Data  Base  software  component  function  shall  be  to 
store  and  control  all  terminal  user  interfaces  not  explicitly  reserved  for  one  of 
the  other  components.  These  interfaces  shall  consist  of  all  charts,  graphs, 
and  drawings  depicting  information  directly  available  to  the  user  during  a 
design  aid  session.  This  information  shall  provide  the  user  with  graphic  data 
on  soldier  characteristics  pertinent  to  the  design  of  the  system  being 
specified.  This  component  shall  not  be  directly  accessible  to  the  user; 
however,  the  user  shall  have  indirect  access  to  all  information  contained  in 
the  data  base  through  the  Design  Aid  Interface,  Analysis,  Search  Process 
Record,  or  Knowledge  Acquisition  Interface  components. 

3.1.2  Functional  Allocation 

The  functional  allocations  to  top  level  software  components  shall  reflect  the 
decomposition  of  system  functional  requirements  as  evidenced  in  the 
designated  software  architecture  to  support  Product  3  ease  of  system  access, 
ease  of  usability,  and  simplicity  and  reliability  of  design  for  system  operation 
and  maintenance.  Table  3-1  provides  a  verification  table  relating  system 
requirements  as  specified  by  the  Government  to  the  top  level  software 
component  that  is  assigned  to  fulfill  each  requirement. 

3.1.3  Memory  and  Processing  Time  Allocation 

3.1. 3.1  Memory  Allocation 

The  MANPRINT  Product  3  software  system  shall  operate  on  the  hardware 
suite  as  defined  in  the  hardware  integration  requirements  listed  in  Appendix  I. 
The  Revelation  data  base  management  system  shall  run  on  top  of  the  DOS 
specified  in  the  requirements.  The  exact  system  language  and  support 
software  requirements  shall  be  as  specified  in  Appendix  II.  The  memory 
management  facilities  of  Revelation  shall  enable  Product  3  to  run  well  within 
the  64QK  bytes  of  main  (unmapped)  memory,  which  is  the  memory  limit  of 
80286  machines  running  MS-DOS.  However,  Revelation  shall  also  be  able 
to  take  advantage  of  a  larger  quantity  of  mapped  memory  as  defined  by  the 
Extended  Memory  Standard  (EMS).  The  addition  of  a  RAM  disk  running  in 
mapped  memory  will  enhance  the  execution  time  of  all  modules  and  increase 
the  speed  of  data  searches,  since  a  greater  portion  of  the  software  will  be 


3-5 


Table  3-1.  Functional  Requirements  Verification 


Requirement 


Operating  System 
MS  DOS  3.2  * 

Data  Base  Management 
System  Revelation/Pick  * 

Other  System  Software 
Turbo  C  * 

Utilities  * 

Encryption  ** 

Comm  between  products 
User  Interface 
Menus 
Language 

Command 

Natural 

Glossary 

Mouse 

Saving  and  return 
Color  coding  ** 
Function  keys 
Housekeeping 
Display  colors 
File  selection 
Device  drivers 
Training 
Help 
Editing 

File  Generation 

Graphics 

Printing 

Soldier  Characteristics 
File  Modification 


Top  Level  Software  Component 


DAI  I  SPRI  ANA |  KAI  |T/H  |  ADBI  GDB 


SPR-  Search  Process  Record 
KAI-  Knowledge  Acquisition  Interface 
ADB-  Alphanumeric  Data  Base 


able  to  be  loaded  into  memory  prior  to  execution,  and  therefore  greatly 
reduce  disk  searches.  All  software  components  shall  execute  entirely  in  main 
(unmapped)  memory,  while  data  files  shall  be  swapped  between  mass 
storage  and  main  memory  as  required  for  execution  of  the  individual 
components.  The  design  goal  shall  be  that  the  object  code  residing  in  main 
memory  shall  be  no  greater  than  275K  bytes.  Allocation  to  individual  top 
level  components  shall  be  as  follows: 

a.  Design  Aid  interface:  100K  bytes. 

b.  Search  Process  Record:  25K  bytes. 

This  shall  not  include  the  dynamic  data  structure  as  described  in 
3. 2. 3.2.2.  Appended  search  files  will  be  saved  to  disk  in  a 
temporary  file;  thus,  the  maximum  size  of  a  search  process  record 
is  defined  by  the  amount  of  disk  or  mass  storage  available. 

c.  Analysis:  11  OK  bytes. 

Analysis  routines  shall  be  a  series  of  executable  modules  outside 
of  Revelation  to  be  run  from  within  Product  3  when  explicitly  called 
by  the  user.  Only  the  single  module  being  executed  at  a  particular 
point  in  time  will  be  in  main  memory.  No  individual  analysis 
module  shall  be  larger  than  25K  bytes  of  object  code. 

d.  Knowledge  Acquisition  Interface:  35K  bytes. 

e.  Training/Help:  40K  bytes. 

f.  Alphanumeric  Data  Base:  No  segment  of  a  data  file  shall  be  larger 
than  50K  bytes. 

Only  the  data  files  actively  in  use  during  Product  3  operations  shall 
be  running  in  main  memory. 

g.  Graphics  Data  Base:  No  data  fife  shall  be  larger  than  16K  bytes. 

Only  the  graphics  files  actively  in  use  during  Product  3  operations 
shall  be  running  in  main  memory. 

3.1. 3.2  System  Response  Times 

The  MANPRINT  Product  3  software  program  shall  operate  within  the 
maximum  acceptable  response  times  listed  below: 

a.  From  end  of  user-input  request  to  see  next  screen  until  response  is 
first  visible:  1.0  seconds. 

b.  From  selecting  a  field  until  visual  verification:  .2  seconds. 
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c.  From  entry  of  user-input  request  until  display  of  prompts,  help 
instructions  or  error  messages:  2.0  seconds. 

d.  From  entry  of  user  request  to  first  appearance  of  analysis 
calculations  in  graphic  form:  10.0  '  econds. 

e.  From  selection  of  a  function  until  the  functions  responds:  2.0 
seconds. 

3.1.4  Functional  Control  and  Data  Flow 

3.1 .4.1  Functional  Control 

The  user  shall  initialize  the  system  and  perform  design  aid  session  activities, 
data  update  activities,  or  conduct  system  software  maintenance  activities  via 
the  Design  Aid  Interface  component,  which  shall  be  the  primary  user-system 
control  point  and  interface  for  the  entire  software  system.  To  accomplish 
specific  functions  not  available  in  this  component,  the  Design  Aid  Interface 
shall  transfer  control  to  one  of  the  other  components  as  required;  however, 
upon  completion  of  the  designated  function,  control  shall  always  return  to  the 
Design  Aid  Interface.  Specifically,  the  Design  Aid  Interface  shall  permit 
transfer  of  control  for  the  specified  functions  to  the  following  components: 

a.  Search  Process  Record. 

b.  Analysis. 

c.  Knowledge  Acquisition  Interface. 

d.  Training. 

3.1 .4.2  Data  Flow 

Data  flow  in  Product  3  shall  be  controlled  by  user  input.  Control  between 
user-accessible  top  level  components  shall  be  directed  entirely  by  the  user. 
Data  flow  between  the  user  and  user-accessible  components  shall  be 
primarily  through  cursor  and  menu  control  action.  Data  flow  between  top 
level  software  components  shall  be  primarily  through  pointers  accessing  data 
files.  A  complete  top  level  data  flow  diagram  is  contained  in  Figure  3-2. 

3.1.5  Global  Data 

All  data  that  reside  in  the  Alphanumeric  and  Graphics  Data  Bases  shall  be 
defined  as  global  data.  Global  data  shall  be  permanent,  unless  modified  or 
deleted  through  the  Knowledge  Acquisition  Interface  functions.  These  data 
shall  be  accessible  by  any  of  the  components  that  interact  with  the  user. 
Global  data  requested  during  a  design  aid  session  shall  be  copied  by  the 
Design  Aid  Interface  and  passed  to  the  Search  Process  Record  component 


Figure  3-2.  Top  Level  Data  Flow  Diagram 


and  appended  to  the  Search  Process  Record  list  for  later  review.  All  other 
data  shall  be  considered  to  be  local,  created  by  a  single  component 
sometime  during  its  execution,  and  destroyed  when  execution  of  that 
component  is  complete  and  control  is  transferred  elsewhere. 

3.1.6  Top  Level  Design 

3.1 .6.1  Design  Aid  Interface  TLSC 

3.1 .6.1.1  Purpose 

Given  the  appropriate  user  inputs,  the  Design  Aid  Interface  component  shall: 

a.  Control  the  search  and  extraction  of  information  on  soldier 
characteristics  by  MANPRINT  personnel,  as  necessary  to  select 
and  display  appropriate  design  aid  session  information. 

b.  Request  execution  of  statistical  routines. 

c.  Retrieve  and  display  help  messages  as  required  to  assure  entry  of 
legal  values  and  to  recover  from  entry  syntax  errors. 

d.  Provide  the  capability  to  control  and  display,  as  required,  the 
manual  addition,  modification,  and/or  deletion  of  global  data  bases, 
anchsearch  process  records. 

3.1. 6.1. 2  Objective 

The  objective  shall  be  to  provide  the  user  with  a  complete  set  of  system 
menus,  displays,  prompts,  and  help  messages  for  use  in  design  aid  sessions 
and  for  manual  entries  associated  with  updating  the  system  data  bases 
and/or  system  software.  Product  3  user-system  interface  requirements  shall 
be  designed  in  accordance  with  the  requirements  of  Appendix  III.  Design 
implementation  shall  include,  but  not  be  restricted  to: 

a.  Easy-to-use  system  menus. 

b.  User  selection  of  the  hardware  entry  device  of  choice  (keyboard, 
cursor,  or  mouse). 

c.  User  capability  to  return  to  the  previous  menu,  the  top  level  menu, 
or  the  help  function. 

3.1. 6.1 .3  General  Description 

User  interaction  functions  shall  be  fully  transparent  to  the  user,  while  system 
controlling  and  accessing  functions  shall  be  entirely  hidden  from  the  user. 
Command  language  shall  not  be  used  at  any  point  in  the  user  interface.  The 
Design  Aid  Interface  shall  provide  the  internal  software  routines  to  allow: 
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a.  Direct  user-system  interactions  through  presentation  of  menus  and 
information  on  display  screens. 

b.  Execution  of  user  entry  device  input  signals. 

c.  The  controlling  of  access,  including  transfer  of  control  and  return  of 
control  between  the  Design  Aid  Interface  and  other  top  level 
software  components. 

3.1.6.1.4  Inputs 

During  a  design  aid  session,  the  Design  Aid  Interface  shall  have  the 
capability  to  accept  the  following  types  of  input: 

a.  Data  supplied  by  the  user  in  directing  a  search  process  during  a 
design  aid  session.  The  user  shall  have  the  option  to  input 
keystrokes  directing  the  selection  of  individual  options  from  the 
menus  via  cursor  or  mouse  control  or  by  entry  of  3-5  character 
alphanumeric  sequences  indicating  the  selection  of  a  level  in  the 
taxonomy  of  a  particular  data  file. 

b.  Global  data  extracted  from  the  Alphanumeric  and  Graphics  Data 
Bases  and  transferred  to  the  Design  Aid  Interface.  Inputs  from  the 
Alphanumeric  Data  Base  shall  be  in  the  form  of  ASCII  files.  Inputs 
from  the  Graphics  Data  Base  shall  be  in  the  form  of  bit-mapped 
graphics  files,  which  shall  be  stored  in  compressed  form  and 
expanded  prior  to  display. 

c.  Training  presentation  display  screens  and  text. 

d.  Help  messages  and  displays. 

e.  Statistical  and  data  manipulation  outputs  from  the  Analysis 
component. 

f.  Confirmation  of  instructions  and/or  executions  by  the  Knowledge 
Acquisition  Interface  component. 

3.1 .6.1 .5  Local  Data 

Local  data  shall  be  limited  to  those  sets  of  data  created  as  a  result  of  internal 
component  manipulations  (e.g.,  placeholders  for  keystrokes  that  indicate  the 
search  through  the  information  taxonomy  or  the  transfer  to  a  help  screen).  No 
locally  created  data  shall  be  displayed  to  the  user  and  shall  be  destroyed 
upon  transfer  to  another  component  or  when  additional  memory  is  required 
for  other  operations. 
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3.1. 6.1.6  Sequencing 

The  Design  Aid  interface  component  shall  always  be  the  first  executed  upon 
system  initialization.  The  Design  Aid  Interface  shall  remain  active  at  all  times 
during  a  design  aid  session  unless  user  inputs  initiate  a  transfer  of  control  to 
another  top  level  software  component.  Control  shall  always  transfer  from 
another  component  after  its  completion  back  to  the  Design  Aid  Interface 
component.  The  Design  Aid  Interface  shall  also  control  system  termination. 

3.1 .6.1.7  Processing 

The  Design  Aid  Interface  processing  capabilities  shall  include  data 
manipulation  by  algorithms,  special  control  features,  and  error  handling. 

a.  Algorithms 

The  inputs  into  the  Design  Aid  Interface  shall  be  manipulated 
internally  to  form  a  directed  graph  structure  that  shall  provide  a 
pathway  to  the  the  appropriate  data  base  file  or  files.  Given  a 
directed  graph  structure  in  sufficient  detail  to  make  a  comparison 
between  the  requested  information  and  the  contents  of  a  particular 
data  file,  the  bottom  node  of  the  graph  shall  provide  the  key  into  the 
appropriate  data  file. 

b.  Special  Control  Features 

Using  menu  selection  items,  the  user  shall  have  the  capability  to 
change  display  screen  background  and  alphanumeric  character 
colors. 

c.  Error  Handling 

All  inputs  shall  be  checked  for  proper  syntax  and  legal  values  upon 
entering  into  the  system.  Errors  in  syntax,  legal  values,  and 
requests  for  nonexistent  global  data  files  shall  suspend  program 
execution  and  relay  an  appropriate  message  back  to  the  user. 
Upon  receipt  of  an  error  message,  the  user  shall  automatically  be 
presented  with  the  appropriate  help  information,  instructions,  or 
legal  values.  For  nonexistent  data  files,  the  user  shall  have  the 
capability  to  request  a  listing  of  all  legal  data  files. 

3.1 .6.1 .8  Outputs 

Output  from  the  Design  Aid  Interface  shall  consist  of: 

a.  Display  of  all  system  screens,  including  global  data  from  the  system 
data  bases,  menus,  help,  training,  and  system  update  and  software 
maintenance  screens.  All  sources  shall  be  output  to  the  standard 
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output  device  in  either  a  text  (for  text  files)  or  bit-mapped  (for 
graphics  files)  format. 

b.  Execution  commands  to  other  output  devices  (e.g.,  disk  storage 
devices  or  printers). 

3.1 .6.2  Search  Process  Record  TLSC 

3.1 .6.2.1  Purpose 

The  Search  Process  Record  shall  provide  the  user  access  to  duplicated  data 
files  and  screens  that  record  the  results  of  the  search  process  steps  taken 
during  a  single  design  aid  session  on  Product  3.  Design  aid  session  results 
shall  be  accessible  to  the  user  (via  the  Design  Aid  Interface)  to  enable  the 
user  to  examine  and/or  edit  the  materials  during  the  session  or  at  a  future 
time,  if  the  user  has  designated  that  the  record  be  saved.  Design  aid  session 
results  shall  be  accessible  to  the  user  via  screen  display  or  as  hard  copy 
output  and  shall  consist  of  the  total  set  of  results  or  selected  portions  of  the 
results,  as  designated  by  the  user. 

3.1 .6.2.2  Objective 

The  objective  of  the  Search  Process  Record  component  shall  be  to  receive, 
duplicate,  store,  and  format  for  output  to  the  Design  Aid  Interface  component 
alphanumeric  and  graphic  data  base  files  and  screens.  The  user  shall  have 
the  capability  to  review  and/or  edit  the  files  at  any  time  during  the  design  aid 
session  or  at  a  future  date.  If  the  user  has  not  designated  that  the  design  aid 
session  data  be  saved,  the  data  shall  be  deleted  upon  termination  of  the 
design  aid  session. 

3.1 .6.2.3  General  Description 

The  Search  Process  Record  shall  be  composed  of  a  linked  list  of  text  and 
graphic  screens  created  by  the  Search  Process  Record  component  and 
added  to  through  the  Design  Aid  Interface  component.  Each  screen  display 
shall  be  a  sequential  copy  of  the  equivalent  display  presented  to  the  user. 

The  Search  Process  Record  shall  be  fully  editable  via  a  full  screen  editor  at 
\  any  time  during  the  conduct  of  a  design  aid  session.  Both  intermediate  and 

i  final  Search  Process  Record  products  can  be  saved  to  floppy  or  hard  disk,  or 

printed  in  hard  copy. 

I  3.1.6.2.3.1  Data  Handling 

I  The  Search  Process  Record  shall  create  a  linked  list  at  the  initiation  of  any 

j  design  aid  session  upon  which  alphanumeric  and  graphic  data  shall  be 

appended  and  saved  for  manipulated  later  in  the  search  process.  The  list 
r  shall  store  all  data,  analytical  results,  and  associated  retrieval  displays  in  a 

manner  that  will  provide  the  user  with  a  sequential  record  of  search  materials. 
1  The  Search  Process  Record  shall  provide  the  capability  to  display  one 
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graphic  at  a  time,  along  with  its  accompanying  data  base  information,  if  any. 
At  any  time  during  the  design  aid  session  data  review/edit  process,  the  user 
shall  have  the  capability  to  return  to  the  design  aid  information  search  mode, 
whereupon  the  Search  Process  Record  shall  continue  to  automatically  add 
the  search  results  sequentially  to  the  linked  search  list  at  the  point  of  previous 
exit  from  that  record.  Re-entry  to  the  Search  Process  Record  after  further 
searches  shall  be  at  the  same  point  at  which  exit  occurred.  At  any 
intermediate  point  in  the  view  and  edit  process,  or  at  the  conclusion  of  all 
search  effort,  the  edited  file  shall  have  the  capability  of  being  saved  to  disk 
and  control  returned  to  the  Design  Aid  Interface.  Printing  of  the  output  shall 
be  possible  from  within  the  Search  Process  Record  itself. 

3.1.6.2.3.2  Editing  Capability 

During  a  design  aid  session,  selection  of  the  search  process  record  feature 
shall  permit  the  user  to  move  through  the  previously  searched  files,  one  step 
at  a  time,  to  review  and/or  edit  the  material.  The  editor  shall  provide  the  user 
with  the  capability  to  cut  and  paste  text  or  entire  files,  and  shall  include: 

a.  Full  screen  editing  capabilities,  including  the  ability  to  remove  the 
entire  alphanumeric/graphic  data  combination  from  the  Search 
Process  Record,  remove  only  the  graphic  and  leave  the 
alphanumeric  data,  remove  the  alphanumeric  data  and  leave  only 
the  graphic,  or  make  any  modifications  to  the  alphanumeric  data. 

b.  Editing  of  sections  where  the  design  effort  does  not  require  the 
amount  of  detail  provided,  and  otherwise  prepare  the  records  for 
hard  copy  output. 

3.1 .6.2.4  Inputs 

The  Search  Process  Record  shall  receive  inputs  from  three  sources: 

a.  The  Alphanumeric  Data  Base  component; 

b.  The  Graphics  Data  Base  component;  and 

c.  The  Design  Aid  Interface  component. 

3.1.6.2.4.1  Data  Base  Inputs 

The  major  inputs  shall  be  from  the  Alphanumeric  and  Graphics  Data  Base 
components.  The  Search  Process  Record  shall  extract  text  files  from  the 
alphanumeric  data  base  and  bit-mapped  graphics  files  from  the  graphics 
data  base,  as  directed  by  user  design  aid  session  inputs.  These  files  shall  be 
appended  in  sequential  order  to  a  linked  list  originating  within  the  Search 
Process  Record  component. 
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3.1.6.2.4.2  Design  Aid  Interface  Component  Inputs 

The  Design  Aid  Interface  component  shall  input  its  menu  and  data  input 
screen  to  this  component,  which  shall  also  be  appended  in  sequential  order 
to  the  linked  list.  These  inputs  shall  be  bit-mapped  representations  of  the 
actual  menus  hard-wired  into  the  Design  Aid  Interface.  The  user  shall  have  a 
full  screen  edit  and  a  print  capability  through  the  interface  with  the  Search 
Process  Record.  This  capability  shall  allow  for  the  input  of  instructions  for  the 
cutting  and  pasting  of  text  or  of  entire  files  (linked  list  nodes)  in  the  record, 
and  allow  for  the  hard  copy  output  of  all  or  part  of  the  record. 

3.1 .6.2.5  Local  Data 

Local  data  within  the  Search  Process  Record  shall  be  limited  to  the  structures 
required  for  the  creation  and  modification  of  the  current  design  aid  session 
linked  list,  and  for  the  execution  of  the  full  screen  edit  and  print  functions. 

3.1 .6.2.6  Sequencing 

The  Search  Process  Record  component  shall  be  entered  only  from  the 
Design  Aid  Interface  component.  No  other  user-accessible  component  shall 
be  entered  from  the  Search  Process  Record.  Exit  from  this  component  shall 
be  to  the  Design  Aid  Interface  only. 

3.1 .6.2.7  Processing 

a.  Algorithms 

The  primary  algorithm  used  in  the  Search  Process  Record 
component  shall  be  the  dynamic  memory  allocator  and  linker  that 
accepts  each  item  to  be  added  to  the  record  and  appends  it  onto 
the  directed  graph. 

b.  Special  Control  Features 
Not  Applicable. 

c.  Error  Handling 

The  Search  Process  Record  may  have  two  types  of  errors: 
overflow  of  memory  space  and  editing  errors. 

(1 )  Overflow  of  Memory  Space 

Memory  overflow  errors  may  occur  when  the  record  is 
composed  of  dynamically  allocated  memory  and  not  saved  to 
disk.  When  memory  reserve  has  reached  10%  of  main 
memory,  a  message  shall  be  sent  to  the  user,  with  instructions 
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to  either  save  the  Search  Process  Record  to  disk,  or  to  enter 
the  Search  Process  Record  component  and  edit  the  record. 


(2)  Editing  Errors 

Text  and/or  graphics  editing  errors,  (e.g.f  attempts  to  edit  an 
empty  file,  copy  too  large  an  area  of  text,  etc.)  shall  cause  the 
Search  Process  Record  execution  to  suspend  and  an 
appropriate  error  message  shall  be  transmitted  to  the  user, 
accompanied  by  identification  of  the  probable  error. 

3.1 .6.2.8  Outputs 

The  Search  Process  Record  shall  output  the  following  products: 

a.  Screen  displays  of  the  search  process  list,  to  the  standard  output 
device. 

b.  The  search  process  list,  to  floppy  or  hard  disk. 

c.  The  search  process  list,  to  printer. 

3.1. 6.3  Analysis  TLSC 

3.1. 6.3.1  Purpose 

The  purpose  of  the  top  level  Analysis  component  shall  be  to  provide  the 
capability  to  conduct  analyses  of  the  alphanumeric  data  stored  in  the 
Alphanumeric  Data  Base  component.  The  Analysis  component  shall  not  have 
the  capability  to  perform  analysis  of  stored  Graphics  Data  Base  data. 
Statistical  routines  shall  be  defined  externally  to  the  Product  3  data  base 
management  system  and  shall  be  input  to  the  Analysis  component  by  use  of 
the  redirection  operator.  The  user  shall  be  provided  with  the  capability  to: 

a.  Transform  quantitative  information  from  its  stored  form  to  a  user- 
selected  display  form. 

b.  Adjust  data  for  variations  in  population  and  context. 

c.  Take  correlations  and  time  relationships  between  variables  into 
account. 

3.1. 6.3.2  Objective 

The  objective  of  the  top  level  Analysis  component  shall  be  to  provide  the 
capability  for  the  user  to  apply  statistical  operations  to  manipulate  and 
customize  stored  soldier  characteristic  alphanumeric  data  to  derive 
customized  design  information. 
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3.1. 6.3.3  General  Description 

The  Analysis  component  shall  contain  the  following  sets  of  operations: 

a.  Descriptive  Statistics 

The  design  goal  shall  be  to  provide  the  j  descriptive  statistics 
operations  to  permit  the  user  to  generate  descriptive  statistics  that 
do  not  already  reside  in  the  Alphanumeric  Data  Base.  However, 
the  final  number  of  lower  level  software  components  shall  be 
determined  during  the  detailed  prototype  design  phase  and  shall 
be  dictated  by  the  results  of  detailed  design  tests  with  actual  data. 

b.  Transformations 

The  transformation  operations  shall  accomplish  two  distinct  tasks 
which  provide  the  user  with  the  capability  to: 

(1)  Change  already-existing  data  base  information  into  other 
forms,  using  transforms  (logarithms,  powers,  and  roots),  or 
enable  the  combination  of  data  in  cases  where  more 
aggregate  information  may  be  desired. 

(2)  Enable  the  plotting  of  transformed  data,  to  allow  the  user  to 
test  different  transformations  and  compare  the  output  graphs 
to  determine  which  transformation  offers  the  most  utility. 

c.  Correlations/Predictions 

The  correlation/pred  utive  operations  shall  provide  the  user  with  the 
capability  to: 

(1 )  Establish  a  simple  or  multiple  correlation  coefficient  between 
two  or  more  variables  contained  within  a  single  data  file,  :r 
across  multiple  data  files  to  enable  the  user  to  establish 
customized  relationships  or  dependencies  that  are  not 
available  within  the  stored  data  bases. 

(2)  Establish  time'  series  models  to  project  characteristics  or  other 
data  over  periods  of  time  not  expressively  covered  by  the  data 
itself. 

3.1. 6.3.4  Inputs 

Inputs  to  the  Analysis  component  shall  consist  of  entire  alphanumeric  data 
files  or  specified  variables  extracted  from  single  files  or  across  multiple  files. 
The  Analysis  component  shall  have  the  capability  to  accept  free-form  and/or 
specifically  formatted  data.  Dynamic  memory  shall  be  utilized  to  maximize 
the  efficiency  of  the  analytic  operations. 
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3.1. 6.3.5  Local  Data 

Local  data  structures  shall  be  created  to  support  the  development  of 
appropriate  statistical  results.  The  design  goal  shall  be  to  implement  these 
structures  as  dynamically  as  possible  to  assist  in  memory  management. 
Efficient  processing  shall  require  the  creation  of  matrices  for  a  number  of  the 
calculations.  The  results  of  the  internal  calculations  shall  be  transmitted  from 
the  Analysis  component  to  the  Design  Aid  Interface  component  to  be 
displayed  to  the  user  for  review  and/or  editing. 

3.1. 6.3.6  Sequencing 

The  Analysis  component  shall  be  entered  only  from  the  Design  Aid  Interface 
component  and  shall  exit  by  user  action  to  the  Design  Aid  Interface 
component  only.  Access  by  the  Design  Aid  Interface  to  the  Analysis 
component  shall  be  available  at  any  time  during  a  design  aid  session. 

3.1. 6.3.7  Processing 

a.  Algorithms 

The  Analysis  component  shall  include  standard  algorithms  for  the 
computation  of  common  statistical  functions.  The  set  of  standard 
algorithms  shall  include,  as  a  minimum,  mean,  standard  deviation, 
variance,  quantities,  distributions,  equation  transformations, 
correlation  coefficients,  simple  and  multiple  regressions,  and 
moving  average,  autoregressive,  and  ARIMA  time  series 
components. 

b.  Special  Control  Features 
Not  Applicable. 

c.  Error  Handling 

The  Analysis  component  may  encounter  errors  in  which  the  user 
calls  for  execution  of  specific  statistical  tests  with  inappropriate  or 
an  incorrect  number  of  parameters.  Such  errors  shall  be  handled 
as  follows: 

(1)  Each  statistical  operation  entry  shall  be  accompanied  by  a 
prompt,  describing  the  number  and  type  of  parameters  that  are 
expected  by  the  operation.  Further  Help  functions  shall  be 
available  for  each  analytical  operation,  describing  the  purpose 
of  the  operation  and  the  type  of  information  that  can  be 
obtained  through  use  of  the  operation.  Help  instruction  shall 
include  examples  of  sample  data  inputs  and  outputs. 
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(2)  Given  an  error  arising  as  a  result  of  an  attempt  to  execute  a 
module  without  appropriate  inputs,  an  error  message  shall  be 
transmitted  to  the  user,  accompanied  by  appropriate  help 
instructions. 

(3)  The  Analysis  component  shall  not  have  the  capability  to 
identify  errors  in  semantics  (e.g.,  errors  of  input  content  that 
are  meaningless  or  errors  of  output  content  which  are 
nonsensical).  However,  it  shall  be  a  design  goaf  to  provide  an 
■intelligent"  approach  to  the  evaluation  of  Analysis  operations. 

3.1. 6.3.8  Outputs 

The  output  of  the  Analysis  component  shall  be  information  generated  as  a 
result  of  one  or  more  Analysis  operations.  This  information  shall  consist  of 
standard  statistical  results  (e.g.,  mean,  standard  deviation,  transformed  data, 
and  regression  equations).  The  output  shall  be  automatically  saved  as 
temporary  text  files  and  appended  to  the  Search  Process  Record  list.  The 
user  shall  have  the  capability  to  save  one  or  more  of  the  files  as  a  permanent 
file.  Permanent  files  may  be  added  to  the  permanent  alphanumeric  data 
base  as  a  data  base  update  activity,  using  the  Knowledge  Acquisition 
Interface  to  place  the  file  and  draw  the  appropriate  file  links. 

3.1. 6.4  Knowledge  Acquisition  Interface  Component 

3.1 .6.4.1  Purpose 

The  Knowledge  Acquisition  Interface  shall  provide  the  capability  to  manually 
and  automatically  update  and  modify  the  Product  3  Alphanumeric  and 
Graphics  Data  Base  contents.  Manual  update  operations  shall  be  performed 
on  the  Alphanumeric  Data  Base  only.  Automatic  update  operations  shall  be 
performed  on  both  the  Alphanumeric  and  Graphics  Data  Base.  Within  the 
constraints  of  both  the  manual  and  automatic  entry  mode,  the  Knowledge 
Acquisition  Interface  shall  provide  the  capability  to: 

a.  Search  for  and  replace,  modify,  and/or  delete  discrete  data 
elements  of  already-existing  data. 

b.  Search  for  and  add  new  data  to  the  existing  data  structure. 

c.  Search  for  and  add,  modify,  and/or  delete  existing  data  structures 
or  elements  of  data  structures. 

d.  Ensure  permanent  attachment  of  new  files  to  the  search  taxonomy. 
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3.1 .6.4.2  Objective 

The  objective  of  the  Knowledge  Acquisition  Interface  shall  be  as  follows: 

a.  Permit  a  knowledgeable  user  to  locate  a  particular  element  in  the 
database  and  change  it,  within  the  constraints  of  the  applicable 
data  structure. 

b.  Permit  a  naive  user  to  locate  the  proper  area  of  the  database  in 
order  to  add  new  data  in  conformance  with  the  data  structures  of 
like  data  already  residing  in  the  database. 

3.1. 6.4.3  General  Description 

Given  appropriate  user  access  and/or  security  identification,  the  Knowledge 
Acquisition  Interface  top  level  component  shall  provide  the  capability  to  enter 
changes  to  the  Product  3  alphanumeric  and  graphics  data  bases  via  manual 
or  automatic  means  The  Knowledge  Acquisition  Interface  shall  accept, 
control,  and  confirm  data  base  changes  through: 

a.  Manual  inputs  from  the  system  workstation  keyboard.  In  the 
manual  mode,  the  user  shall  be  led  through  complete  system 
decomposition  and  levels  of  functional  abstractions  to  the  exact 
point  in  the  data  base  where  the  changes  will  occur.  For  all 
deletions  of  data,  the  user  shall  be  requested  to  confirm  the  entered 
deletion  instructions  prior  to  execution  by  the  Knowledge 
Acquisition  Interface.  For  entry  of  new  data  and/or  modification  of 
new  data,  the  Knowledge  Acquisition  Interface  shall  output  for 
display  to  the  user,  the  maximum  field  lengths  for  each  identified 
data  element.  In  all  manual  entry  activities,  the  user  shall  have  the 
capability  to  cancel  inputs  at  any  time  prior  to  final  confirmation  and 
implementation  of  the  changes  and  the  user  shall  be  provided  with 
the  capability  to  edit  the  proposed  changes. 

b.  Compatible  floppy  disks  and/or  Bernoulli  removable  disks. 

3.1. 6.4.4  Inputs 

The  Knowledge  Acquisition  Interface  shall  accept  the  following  types  of 
inputs: 

a.  Text  files  to  be  associated  with  the  alphanumeric  data  base. 

b.  Bit-mapped  graphics  files  associated  with  the  graphics  data  base. 

3.1 .6.4.5  Local  Data 

Knowledge  Acquisition  Interface  local  data  shall  be  generated  for  creation  of 
the  directed  acyclic  graph  structure  required  to  place,  modify,  or  delete  data 
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items  or  files,  including  adjustment  of  changed  files,  within  the  Alphanumeric 
or  Graphics  Data  Base  components. 

3.1. 6.4.6  Sequencing 

a.  For  purposes  of  changing  the  Product  3  data  bases,  manual  entry 
user-system  interface  commands  shall  flow  to  and  from  the  Design 
Aid  Interface  component  and  the  Knowledge  Acquisition  Interface 
component  only. 

b.  For  purposes  of  controlling  the  changes  to  the  system  data  bases, 
information  and  instructions  shall  flow  to  and  from  the  Knowledge 
Acquisition  Interface  to  the  Alphanumeric  Data  Base  and/or  the 
Graphics  Data  Base. 

3.1 .6.4.7  Processing 

a.  Algorithms 
Not  applicable. 

b.  Special  Control  Features 
Not  applicable. 

c.  Error  Handling 

Three  types  of  errors  may  occur  within  the  Knowledge  Acquisition 
Interface  component: 

(1 )  Errors  that  occur  due  to  lack  of  mass  storage  capability.  Upon 
confirmation  of  data  base  change  activities  but  prior  to  the 
actual  accomplishment  of  the  updating  activity,  the  Knowledge 
Acquisition  Interface  component  shall  size  an  input  and 
compare  its  size  with  the  amount  of  mass  storage  remaining. 
When  the  size  of  the  input  is  greater  than  the  largest  fragment 
of  storage  remaining,  the  component  shall  first  attempt  to 
coalesce  files  to  attempt  to  create  the  required  storage  space. 
If  the  required  storage  space  cannot  be  achieved,  the 
Knowledge  Acquisition  interface  component  shall  provide  the 
user  with  a  message  signifying  that  there  is  insufficient 
storage.  These  or  other  files  may  then  be  transferred  to  a 
Bernoulli  disk  or  floppy  disk. 

(2)  Errors  that  occur  when  incorrect  data  is  entered  into  a  file.  To 
reduce  the  probability  of  incorrect  entry,  the  Knowledge 
Acquisition  Interface  shall  have  the  capability  of: 

(a)  Echoing  inputs  back  to  the  user,  and 
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(b)  Requiring  positive  acknowledgement  by  the  user  before 
making  the  requested  changes. 

(3)  Errors  that  occur  when  an  incorrect  pathway  to  a  new  file  has 
been  constructed.  The  component  shall  provide  the  user  with 
as  clear  a  path  choice  as  possible  when  placing  a  new  file 
through  the  use  of  the  same  taxonomy  as  that  used  in  the 
design  search. 

3.1.S.4.8  Outputs 

The  top  level  Knowledge  Acquisition  Interface  component  shall  output  to  the 
default  mass  storage  device  all  file  modifications  and  add  new  files  as 
specified  by  the  user.  These  outputs  shall  include  text  modifications  and  new 
text  files  into  the  alphanumeric  data  base,  and  new  graphics  fiies  into  the 
graphics  data  base.  All  changes  and  additions  made  to  either  data  base 
shall  result  in  confirmations  being  returned  through  the  Knowledge 
Acquisition  Interface  to  the  user. 

3.1. 6.5  Training/Help  TLSC 

3.1 .6.5.1  Purpose 

The  Training/Help  functions  shall  ensure  that  the  user  has  the  information 
available  to  conduct  a  design  aid  session  efficiently  and  with  a  minimum  of 
errors.  The  user  shall  be  able  to  gain  an  understanding  of  the  functionality  of 
the  system  and  be  offered  a  clear  and  unambiguous  path  at  each  step  in  the 
search  process.  Help  shall  be  available  at  every  point  in  the  process  that 
gives  the  user  an  option  in  selecting  the  next  search  space,  'n  addition,  there 
shall  be  enough  information  provided  to  the  individual  supporting  and 
maintaining  the  system  so  that  all  errors  and  system  modifications  can  be 
competently  addressed. 

3.1 .6.5.2  Objective 

3.1.6.5.2.1  Training  Objectives 

Training  objectives  for  the  top  level  Training  and  Help  software  component 
shall  include  providing  user  personnel  with  the  capability  to  obtain  a 
comprehensive  system  overview;  to  instruct  new  users  on  how  to  conduct  a 
design  aid  session;  and  instruct  users  how  to  request  help  instructions 
beyond  that  help  which  is  automatically  presented  in  the  conduct  of  system 
operations. 

3.1.6.5.2.2  Help  Objectives 

Help  objectives  for  the  help  function  shall  be  to  enable  the  user  to  conduct  a 
design  aid  session  efficiently  and  with  a  minimum  of  errors.  The  help  option 
shall  provide  the  user  with  the  capability  to  obtain  information  at  all  junctures 
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in  the  design  aid  session  where  one  or  more  options  shall  be  selected  by 
the  user  to  prescribe  the  next  design  aid  session  process  ,  and  where  user- 
inputs  cause  system  errors.  In  addition,  the  help  function  will  provide 
assistance,  via  help  screens,  when  performing  local  system  data  base 
updates  and/or  local  system  software  maintenance  activities. 

3.1. 6.5.3  General  Description 

3.1.6.5.3.1  Training 

There  shall  be  two  training  options  available  for  user  selection: 

a.  A  system  overview  option  that  shall  present  a  comprehensive 
overview  of  the  system,  including  a  description  of  the  intended 
purpose  of  Product  3,  to  give  the  user  a  conceptual  understanding 
of  the  organization  of  the  Product  3  system. 

b.  An  on-line  training  capability  to  enable  naive  or  inexperienced 
design  session  aid  user  personnel,  including  user  personnel  with 
little  or  no  computer  experience,  to  understand  how  to  use  Product 
3  to  obtain  system  design  specification  requirements.  A 
comprehensive  on-line  tutorial  "sample"  design  session  aid 
training  program  shall  be  provided,  in  which  user  personnel, 
immediately  upon  turning  the  system  on,  shall  have  the  option  to 
select  a  sample  design  aid  session  tutorial.  The  user  shall  be  led 
through  a  hypothetical  design  scenario  and,  drawing  upon  actual 
data  base  files,  be  taught  how  to  search  through  the  data  base  for 
relevant  design  information;  how  to  browse,  edit,  and  save 
Search  Process  Record  files;  and  how  to  print  out  hard  copies  of 
the  results.  The  tutorial  shall  assist  the  user  in  gaining  an 
understanding  of  the  functionality  of  the  system  and  how  to  select 
clear  and  unambiguous  paths  at  each  step  in  a  design  aid 
session.  At  no  time  during  the  tutorial  presentation  shall  the  user 
be  required  to  provide  technical  inputs. 

3.1.6.5.3.2  Help 

On-line  help  shall  be  available  for  each  display  screen  at  which  the  user  has 
an  option  as  to  the  direction  to  proceed.  This  shall  occur  whenever  menus 
are  displayed,  giving  the  user  a  list  of  possible  alternatives  to  select.  Help 
shall  not  be  available  on  screens  displaying  alphanumeric  or  graphics 
design  information.  Two  types  of  help  shall  be  available: 

a.  A  short  text  that  shall  be  displayed  whenever  the  user  selects  a 
menu  options  and/or  where  a  screen  requests  a  user  to  enter  a 
particular  item  of  information  in  order  to  proceed.  The  text  shall  be 
displayed  at  the  bottom  of  the  screen  and  shall  give  the  user  a 
brief  description  of  the  option  or  legal  values  that  can  be  selected. 
This  assistance  shall  act  as  a  quick  reference  guide  and  memory 
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jogger  to  the  experienced  user  needing  a  reminder  of  the 
functionality  of  the  system  and/or  to  an  inexperienced  user 
requiring  information  on  system  data  entry  requirements.  The 
training  review  shall  be  available  at  system  initialization  or  upon 
termination  of  the  design  aid  session. 

b.  Through  the  activation  of  a  keyboard  function  key,  the  presentation 
of  help  screens  which  shall  provide  a  more  complete  description 
of  the  choices  available  at  that  point  in  the  search  or  where  a 
screen  requests  a  user  to  enter  a  particular  item  of  information  in 
order  to  proceed.  These  descriptions  may  take  up  to  the  entire  full 
screen,  and  shall  be  comprehensive  enough  to  instruct  the 
inexperienced  user.  Each  selection  available  at  that  point  in  the 
search  shall  be  described  in  detail,  giving  both  the  purpose  of  the 
selection  and  the  direction  it  will  lead  the  user  in  the  search. 
Exiting  from  the  help  screen  shall  return  the  user  back  to  the 
original  screen  display.  Help  shall  be  available  at  any  point  in  a 
design  aid  session. 

3.1 .6.5.4  Inputs 

Inputs  required  for  the  Training/Help  component  shall  be  those  which  select 
the  training/help  menu  item  and/or  the  activation  of  the  terminal  keyboard 
Help  function  key. 

3.1 .6.5.5  Local  Data 

Training/Help  local  data  shall  consist  of  textual  data  making  up  the  content 
of  the  help  messages. 

3.1 .6.5.6  Sequencing 

The  Training/Help  top  level  software  component  shall  be  called  from  the 
Design  Aid  Interface  component  only.  The  training  component  shall,  in  turn, 
call  a  sequence  of  other  system  components,  as  required,  to  conduct  the 
sample  design  aid  session.  Control  shall  remain  within  the  Design  Aid 
Interface  when  help  functions  are  called. 

3. 1.6. 5.7  Processing 
a.  Algorithms 

No  algorithms  shall  be  required  to  implement  the  Help  facility.  The 
training  module  running  a  sample  design  aid  session  shall  be 
implemented  with  an  algorithm  to  call  the  Design  Aid  Interface 
component  internally  and  to  proceed  through  the  top  level 
software  components  as  a  real  design  search  would. 
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b.  Special  Control  Features 
Not  Applicable. 

c.  Error  Handling 
Not  Applicable. 

3.1 .6.5.8  Outputs 

Outputs  to  the  help  facility  shall  be  textual  messages  directed  to  the  standard 
output  device.  Outputs  to  the  training  facility  shall  be  textual  messages  and 
screen  displays  to  the  standard  output  device  making  up  a  sample  design 
search.  The  user  shall  have  the  option  of  directing  this  search  to  the  printer. 

3.1 .6.6  Alphanumeric  Data  Base  TLSC 

3.1. 6.6.1  Purpose 

The  Alphanumeric  Data  Base  shall  accept,  store,  process  and  control 
Alphanumeric  Data  Base  information  to  provide  data  that  is  of  value  to  an 
Army  weapon  or  support  system  designer.  These  data  shall  be  organized  in 
files  based  on  a  logical  taxonomy  enabling  access  of  the  data  from  system 
descriptions  and  requirements  provided  by  the  user.  The  design  goal  shall 
be  to  organize  and  present  the  data  in  a  way  that  will  assist  in  to  the 
accomplishment  of  the  objectives  of  the  system  designer. 

3.1 .6.6.2  Objective 

The  objective  of  the  Alphanumeric  Data  Base  shall  be  to  enable  presentation 
of  alphanumeric  design  data  in  the  form  of  text,  tabular,  and  statistical  form. 

3.1 .6.6.3  General  Description 

The  Alphanumeric  Data  Base  component  shall  be  composed  of  ASCII- 
formatted  text  files.  These  files  shall  be  accessed  through  the  Design  Aid 
Interface  by  the  design  search  process,  and  shall  be  displayed  to  the  user  as 
required.  The  exact  files  and  individual  data  items  to  be  displayed  to  the  user 
shall  be  determined  by  the  search  method  contained  in  the  Design  Aid 
Interface  component. 

3.1 .6.6.4  Inputs 

The  Alphanumeric  Data  Base  component  shall  receive  inputs  from  the 
Design  Aid  Interface  component  and  the  Knowledge  Acquisition  Interface 
component.  From  the  Design  Aid  Interface  it  shall  receive  a  pointer  to  a 
particular  file  to  be  displayed  to  the  user.  From  the  Knowledge  Acquisition 
Interface  it  shall  receive  new  text  files  to  be  included  as  a  part  of  the  data 
base. 
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3.1 .6.6.5  Local  Data 
Not  Applicable. 

3.1.6.6.6  Sequencing 

The  Alphanumeric  Data  Base  component  shall  consist  of  passive  text  files. 
Therefore,  it  shall  not  execute  per  se,  but  shall  be  accessed  only  in  response 
to  requests  from  other  components  (e.g;  the  Design  Aid  Interface  and  the 
Knowledge  Acquisition  Interface  components).  These  accesses  shall  be 
controlled  by  the  search  process  from  the  Design  Aid  Interface,  and  by  the 
update  process  from  the  Knowledge  Acquisition  Interface. 

3.1. 6.6.7  Processing 

a.  Algorithms 

Data  files  shall  be  organized  and  accessed  using  the  REVELATION 
LHASH  algorithm. 

b.  Special  Control  Features 

Not  Applicable. 

c.  Error  Handling 

An  error  may  occur  when  the  Design  Aid  Interface  component 
request  access  to  a  nonexistent  file;  that  is,  requests  for  files 
inadvertently  removed  from  the  data  base  by  the  user  or  lost 
because  of  disk  error.  When  a  request  is  made  for  a  non-existent 
file,  an  error  message  shall  be  transmitted  to  the  user,  stating  the 
probable  cause  of  the  error  and  accompanying  help  instructions. 

3.1. 6.6.8  Outputs 

Outputs  from  the  Alphanumeric  Data  Base  component  shall  be  extracts  from 
text  data  files,  which  are  passed  to  the  Design  Aid  Interface  and  presented  to 
the  user.  Data  from  these  Alphanumeric  Data  Base  files  may  also  be  passed 
to  the  Analysis  component,  where  they  are  used  as  input  to  one  or  more  of 
the  Analysis  modules. 

3.1 .6.7  Graphics  Data  BaseTLSC 

3.1. 6.7.1  Purpose 

The  Graphics  Data  Base  component  shall  define  the  structure,  format,  and 
content  of  all  terminal  data  screens  displaying  graphical  information.  These 
screen  displays  shall  exist  in  data  base  files  separate  from  the  Alphanumeric. 
Data 
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Base,  and  shall  represent  static  information  that  may  be  combined  with  text 
files  to  produce  an  information  display  appropriate  to  the  Army  system  being 
designed. 

3.1 .6.7.2  Objective 

The  top  level  Graphics  Data  Base  software  component  shall  be  designed  to 
accept,  control,  process  and  transmit  bit-mapped  graphic  images. 

3.1 .6.7.3  General  Description 

The  Graphics  Data  Base  component  shall  contain  only  bit-mapped  graphical 
images  placed  in  data  files  on  the  MANPRINT  Product  3  system's  mass 
storage  device.  It  shall  not  include  intermediate  screen  displays  in  any  of  the 
directly  user-accessible  software  components,  or  any  of  the  graphical  output 
produced  as  a  result  of  the  execution  of  any  of  the  modules  in  the  Analysis 
component.  These  graphics  shall  include  drawings,  complete  with 
measurements,  of  relevant  human  engineering  information;  graphs,  usually 
depicting  performance  parameters,  relationships,  and  rates;  and  charts 
displaying  pertinent  summaries  of  information.  The  Graphic  Data  Base  files 
shall  be  entered  into  the  Product  3  graphics  data  base  by  scanning  and 
digitizing  already-existing  graphics,  by  redrawing  existing  graphics  or 
drawing  new  graphics  based  on  information  available  in  source  documents, 
or  by  generating  EGA-based  graphics  from  textual  information  already  within 
the  data  base. 

3.1 .6.7.4  Inputs 

The  Graphics  Data  Base  component  shall  receive  inputs  from  the  Design  Aid 
Interface  component  and  the  Knowledge  Acquisition  Interface  component 
and  shall  receive  data  file  requests  from  the  Analysis  Component.  From  the 
Design  Aid  Interface  it  shall  receive  a  pointer  to  a  particular  file  to  be 
displayed  to  the  user.  From  the  Knowledge  Acquisition  Interface  it  shall 
receive  new  bit-mapped  graphics  files  to  be  included  as  a  part  of  the  data 
base. 

3.1 .6.7.5  Local  Data 
Not  Applicable. 

3.1. 6.7.6  Sequencing 

The  Graphics  Data  Base  component  shall  consist  of  passive  graphics  files. 
Therefore,  it  shall  not  execute  per  se,  but  shall  be  accessed  only  in  response 
to  requests  from  other  components,  e.g.,  the  Design  Aid  Interface  and  the 
Knowledge  Acquisition  Interface  components.  These  accesses  shall  be 
controlled  by  the  search  process  from  the  Design  Aid  Interface,  and  by  the 
update  process  from  the  Knowledge  Acquisition  Interface. 
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3.1. 6.7.7  Processing 

a.  Algorithms 

Data  files  shall  be  organized  and  accessed  using  the  REVELATION 
LHASH  algorithm. 

b.  Special  Control  Features 
Not  Applicable. 

c.  Error  Handling 

An  error  may  occur  when  the  Design  Aid  Interlace  component 
requests  access  to  a  nonexistent  file;  that  is,  requests  for  files 
inadvertently  removed  from  the  data  base  by  the  user  or  lost 
because  of  disk  error.  When  a  request  is  made  for  a  non-existent 
file,  an  error  message  shall  be  transmitted  to  the  user,  stating  the 
probable  cause  of  the  error  and  accompanying  help  instructions. 

3.1. 6.7.8  Outputs 

Outputs  from  the  Graphics  Data  Base  component  shall  be  bit-mapped 
graphics  files, -which  are  passed  to  the  Design  Aid  Interface  and  presented  to 
the  user. 

3.1.7  Adaptation  Data 

All  sites  with  the  hardware/software  components  specified  in  the  ARI  System 
Integration  Guidelines  (Appendix  I)  shall  be  able  to  accept  the  MANPRINT 
Product  3  software  system  without  modification.  Those  sites  without  a 
removable  hard  disk  capability  shall  be  required  to  download  Product  3  from 
floppy  disks  into  a  fixed  hard  disk  of  at  least  20  megabytes. 

3.1.8  System  Maintenance 

System  maintenance  shall  consist  of  two  separate  functions: 

a.  Updating  information  contained  in  the  alphanumeric  and/or 
graphics  data  bases. 

b.  Maintaining  Product  3  user  accounts  and  access  privileges. 

3.1 .8.1  Data  Base  Maintenance 

All  data  base  maintenance  shall  occur  from  the  Knowledge  Acquisition 
Interface  top  level  software  component.  Access  to  this  component  shall  be  by 
authorized  personnel  only.  Access  shall  be  managed  in  accordance  with  the 
procedures  in  Section  3.1. 8.2.  The  system  shall  offer  the  option  of  either 


manual  or  automatic  updating  tor  the  alphanumeric  data  base.  The  graphics 
data  base  shall  be  updated  automatically  only.  Automatic  update  shall  occur 
from  a  mass  storage  device  (e.g.,  floppy  or  Bernoulli  hard  disk).  Updating 
activities  shall  include  the  following: 

a.  Editing  existing  alphanumeric  files. 

b.  Adding  or  replacing  entire  alphanumeric  or  graphic  files. 

c.  Adding  or  modifying  taxonomic  pathways  accessing  the  files. 

d.  Preparation  of  files  in  the  DIF  format  for  file  transfer. 

3.1. 8.2  Account/Access  Maintenance 

Account/access  maintenance  shall  be  a  menu  item,  accessible  by  authorized 
personnel  only.  Selection  of  the  maintenance  menu  option  shall  permit  the 
following  operations: 

a.  Add  account  number/password. 

Permits  the  addition  of  an  account  number  and  password  for  a  new 
Product  3  user. 

b.  Delete  account  number/password. 

Permits  the  removal  of  an  account  number  and  password  for  a 
noncurrent  user. 

c.  Change  password. 

Permits  the  modification  of  a  password  for  a  current  user. 

d.  Add  privileges. 

Permits  the  addition  of  system  access  privileges  to  the  account  of  a 
current  user.  Privileges  include:  conduct  design  search,  write  to 
disk,  modify  data  base,  and  access  system  maintenance. 

e.  Delete  Privileges. 

Permits  the  deletion  of  system  access  privileges  to  the  account  of  a 
current  user.  Privileges  include:  conduct  design  search,  write  to 
disk,  modify  data  base,  and  access  system  maintenance. 
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3.2  Detailed  Design  Requirements 

3.2.1  Interface  Design 

The  system  interfaces  between  the  Product  3  top  level  software  components 
shall  be  as  configured  and  illustrated  in  Figure  3-2.  The  major  interfaces 
shall  include  those  associated  with  the  Design  Aid  Interface,  the  Search 
Process  Record,  the  Analysis,  and  the  Knowledge  Acquisition  Interface 
components. 

3.2.1.1  Design  Aid  Interface 

The  major  interfaces  of  the  Design  Aid  Interface  shall  include  the  interfaces 
with  the  Search  Process  Record,  the  Analysis,  the  Knowledge  Acquisition 
Interface,  Training  and  Help,  the  Alphanumeric  Data  Base  and  the  Graphics 
Data  Base  components. 

3.2.I.I.!  Design  Aid  Interface/Search  Process  Record 

Transfer  of  control  shall  be  exchanged  between  the  Design  Aid  Interface 
component  and  the  Search  Process  Record  component,  as  required  by  the 
internal  design  aid  interface  software  processes.  Transfer  of  control  shall 
occur  when  the  Search  Process  Record  is  appending  screen  displays  and 
data  base  files  generated  by  the  design  search  to  a  directed  acyclic  list 
maintained  by  the  Search  Process  Record.  The  files  appended  to  this  list 
shall  be  either  text  and/or  bit-mapped  graphic  files,  and  shall  include 
appended  screen  displays  generated  by  the  Design  Aid  Interface 
component.  All  other  data  shall  flow  from  the  Design  Aid  Interface  to  the 
Search  Process  Record  component  only.  Copies  of  the  data  files  shall  be 
used,  rather  than  pointers  to  the  actual  files,  to  enable  editing,  saving,  and 
printing  of  the  record. 

3.2.1 .1.2  Design  Aid  Interface/Analysis 

Direction  of  data  flow  other  than  that  required  for  control  transfer  shall  be 
from  the  Design  Aid  Interface  component  to  the  Analysis  component  only. 
The  text  data  files  selected  to  be  input  into  a  particular  Analysis  module  shall 
be  transferred  into  that  module  through  the  use  of  the  MS  DOS  redirection 
("piping")  operation.  The  Analysis  component  shall  have  its  own  menu-  and 
output-driven  user  interface  and  therefore  there  shall  be  no  requirement  to. 
return  data  from  the  Analysis  component  to  the  Design  Aid  Interface 
component,  other  than  that  required  to  return  control  to  the  Design  Aid 
Interface.  The  Design  Aid  Interface  component  shall  have  the  capability  to 
enable  transfer  of  control  between  the  Design  Aid  Interface  component  and 
the  Analysis  component  when  the  analysis  component  receives  instructions 
to  accomplish  statistical  evaluations.  Statistical  evaluation  instructions  shall 
include: 
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a.  Preparation  of  descriptive  statistics  not  found  in  the  data  files 
themselves; 

b.  Transformation  of  data  into  forms  that  can  be  saved  as  separate 
files  and  input  into  other  analysis  modules  or  that  can  be  output 
directly  with  greater  meaning  and  utility  to  the  design  process;  and 

c.  Preparation  of  correlations  or  other  adjustments,  such  as  time 
series  that  can  be  used  enhance  the  predictive  value  of  the  data. 

3.2.1. 1.3  Design  Aid  Interface/Knowledge  Acquisition 

Direction  of  data  flow  other  than  that  required  for  control  transfer  shall  be 
from  the  Knowledge  Acquisition  Interface  component  to  the  Design  Aid 
Interface  Component  only.  Control  transfer  shall  enable  the  user  to  enter 
new  or  modified  data  either  manually  or  from  a  transportable  storage 
medium  into  the  Product  3  data  bases.  Given  entry  of  new  data  files,  new 
links  shall  be  constructed  by  passing  the  pathways  to  the  data,  which  will 
then  connect  the  taxonomy  used  by  the  Design  Aid  Interface  to  access  the 
new  data  files.  These  pathways  shall  be  either  drawn  by  the  user,  with 
assistance  by  the  interface,  in  the  case  of  manual  update,  or  by  an  already 
existing  path,  in  the  case  of  transportable  storage  medium  update. 

3. 2. 1.1. 4  Design  Aid  Interface/Training  and  Help 

The  Training/Help  component  shall  consist  of  two  lower  level  software 
components:  training  and  help.  Control  transfer  data  shall  be  exchanged 
between  the  training  and  the  Design  Aid  Interface  components.  All  other 
data  shall  be  in  both  directions  between  these  components.  Following 
Training  component  control  instructions,  the  Design  Aid  Interface  shall 
conduct  a  sample  design  aid  search  and  return  the  results  back  to  the 
training  module,  which  shall  present  them,  without  modification,  to  the  user. 
Control  instructions  shall  pass  from  the  Training  module  to  the  design  Aid 
Interface,  which  in  return  shall  pass  the  results  of  the  design  aid  search  as 
defined  by  the  control  instructions  back  to  the  Training  module.  Flow  of  data 
between  the  lower  level  help  components  shall  be  bi-directional.  The  Help 
module  shall  be  fully  integrated  within  the  Design  Aid  Interface.  The  flow  of 
data  between  the  two  shall  be  bi-directional.  From  the  Design  Aid  Interface, 
Help  shall  be  obtained  through  brief  prompts  presented  to  the  user  upon  the 
selection  of  a  menu  option  or  by  data  entry  option  at  any  point  in  the  Design 
Aid  Interface.  For  brief  prompts  the  transfer  between  the  components  shall 
be  automatic.  Use  of  the  data  entry  option  shall  be  by  selection  of  the 
appropriate  function  key.  Each  screen  display  in  the  Design  Aid  Interface 
shall  have  an  accompanying  Help  display.  The  user,  by  activating  the  Help 
function  for  a  particular  screen  display,  shall  cause  the  information 
necessary  for  the  selection  of  the  accompanying  Help  display  to  be  passed 
to  the  appropriat3  Help  display.  Upon  completion  of  review,  control  shall  be 
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passed  back  to  the  original  Design  Aid  Interlace  display,  although  no 
information  will  have  passed  across  the  interface. 

3.2.1. 1.5  Design  Aid  Interface/Alphanumeric  Data  Base 

The  flow  of  data  between  these  two  components  shall  be  bi-directional. 
Variables  leading  to  the  selection  of  the  appropriate  alphanumeric  data  file 
shall  pass  from  the  Design  Aid  Interface  component  to  the  designated  file  in 
the  Alphanumeric  Data  Base  component.  The  selected  Alphanumeric  Data 
Base  file  data,  without  modification,  shall  be  passed  to  the  Design  Aid 
Interface  component,  for  display  to  the  user. 

3.2.1 .1.6  Design  Aid  Interface/Graphics  Data  Base 

The  flow  of  data  between  these  two  components  shall  be  bi-directional. 
Variables  leading  to  the  selection  of  the  appropriate  graphics  data  file  shall 
pass  from  the  Design  Aid  Interface  component  to  the  designated  file  in  the 
Graphics  Data  Base  component.  The  selected  Graphics  Data  Base  file  data, 
without  modification,  shall  be  passed  to  the  Design  Aid  Interface  component, 
for  display  to  the  user. 

3.2.1 .2  Search  Process  Record  Interfaces 

The  Search  Process  Record  component  interfaces  with  two  other  top  level 
software  components,  the  Alphanumeric  Data  Base  and  the  Graphics  Data 
Base. 

3.2.1 .2.1  Search  Process  Record/Alphanumeric  Data  Base 

Data  shall  flow  from  the  Alphanumeric  Data  Base  component  to  the  Search 
Process  Record  component.  The  data  transferred  shall  take  the  form  of  text 
files  which  are  extracts  of  identical  files  found  in  the  Alphanumeric  Data 
Base. 

3.2.1 .2.2  Search  Process  Record/Graphics  Data  Base 

Data  shall  flow  from  the  Graphics  Data  Base  to  the  Search  Process  Record 
component.  The  data  transferred  shall  take  the  form  of  bit-mapped  graphics 
files  which  are  copies  of  identical  files  found  in  the  Graphics  Data  Base. 

3.2.1 .3  Analysis/Alphanumeric  Data  Base 

Data  shall  flow  from  the  Alphanumeric  Data  Base  to  the  applicable  lower 
level  analysis  software  component  only  and  shall  consist  of  text  files  of  data 
to  be  entered  directly  into  the  selected  Analysis  component. 


3.2.1 .4  Knowledge  Acquisition  Interface 

The  Knowledge  Acquisition  interfaces  shall  include  interfaces  with  the 
Alphanumeric  Data  Base  and  the  Graphics  Data  Base. 

3. 2. 1.4.1  Knowledge  Acquisition  Interface/Alphanumeric  Data 
Base 

Data  shall  flow  bi-directionally  between  the  Knowledge  Acquisition  interface 
and  the  Alphanumeric  Data  Base.  The  information  transmitted  by  the 
Knowledge  Acquisition  Interface  shall  include  individual  ASCII  numeric 
values  that  are  added  to  individual  data  files  and/or  the  addition  or  deletion 
of  entire  ASCII  text  files.  The  individual  numeric  values  shall  be  intergers  or 
floating  point  numeric  values,  which  can  be  appended  to  the  individual  data 
base  files.  The  numeric  values,  upon  being  appended,  shall  be  capable  of 
being  edited.  Complete  files  shall  be  passed  as  an  ASCII  stream  from  the 
Knowledge  Acquisition  Interface  to  the  Alphanumeric  Data  Base  in  the 
automatic  update  mode  only.  Data  from  the  Alphanumeric  Data  Base  to  the 
Knowledge  Acquisition  Interface  shall  consist  of  process  completion  and 
acknowledgement  data 

3.2.1 .4.2  Knowledge  Acquisition  Interface/Graphics  Data  Base 

Data  flow  between  the  Knowledge  Acquisition  Interface  and  Graphics  Data 
Base  shall  be  possible  in  the  automatic  data  base  update  mode  only.  The 
Knowledge  Acquisition  Interface  shall  act  as  a  conduit  between  a  floppy 
disk  containing  update  files  and  the  Graphics  Data  Base,  taking  files  fromthe 
disk,  placing  them  into  the  data  base,  and  relinking  the  pathways  from  the 
Design  Aid  Interface  to  the  new  files.  These  fields  shall  be  bit-mapped  for 
improved  resolution  and  compressed  in  order  to  save  storage  space,  and 
shall  be  passed  as  a  bit  stream  of  data  words  from  the  Knowledge 
Acquisition  Interface  to  the  Graphics  Data  Base. 

3.2.2  Global  Data 

Global  data  in  Product  3  shall  consist  of  the  text  and  graphic  data  files  that 
comprise  the  Alphanumeric  and  Graphics  Data  Bases,  respectively. 
Alphanumeric  and  Graphics  Data  Base  files  shall  not  be  directly  available  to 
the  user,  but  shall  be  accessible  for  display  through  the  Design  Aid  Interface, 
Analysis,  and  Knowledge  Acquisition  Interface  components.  Entire  text  or 
data  files,  portions  of  text  files,  or  combinations  of  text  and  data  files  shall  be 
passed  through  these  user-accessible  components  and  displayed  to  the 
user.  From  within  the  Design  Aid  Interface  and  Analysis  components,  these 
displays  shall  become  a  part  of  a  design  search.  From  within  the  Knowledge 
Acquisition  Interface,  this  display  shall  assist  a  user  in  updating  data  files. 
Search  Process  Record  lists  shall  consist  of  copies  of  screen  displays  and 
data  that  are  created  and  initialized  in  the  Search  Process  Record  TLSC  but 
for  efficiency  shall  be  maintained  in  the  Design  Aid  Interface  and  Analysis 
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TLSCs,  where  the  actual  screen  displays  are  generated.  Search  Process 
Record  lists  shall  be  passed  between  components  as  required  by  pointer 
address  to  the  head  of  the  list.  Individual  lists  shall  be  composed  of  nodes 
that  are  connected  by  pointers  to  the  address  of  the  next  node.  Each  node 
shall  consist  of  the  data  portion,  which  contains  the  data  or  screen  display, 
and  the  address  portion,  which  contains  the  pointer  to  the  next  node. 

3.2.3  Detailed  Design 

The  Product  3  software  system  shall  be  based  upon  a  relational  data  base  of 
significant  soldier  characteristics.  The  Product  3  data  base  shall  be  divided 
into  two  top  level  software  components,  consisting  of  the  Alphanumeric  Data 
Base  and  the  Graphics  Data  Base  components.  The  other  five  top  level 
software  components  shall  interface  with  the  data  bases  to  assist  the  user  in 
data  reduction,  creation  of  editable  files,  statistical  data  analysis,  data  base 
maintenance,  training,  and  help.  The  data  base  shall  be  designed  in 
accordance  with  the  requirements  of  Appendix  IV,  Data  Base  Structure  and 
User  Presentation,  and  Appendix  V,  Data  Base  Design  Specification.  The 
breakdown  of  top  level  components  into  detailed  components  shall  be  as 
diagrammed  in  Figure  3-3.  Decision  pathways  available  to  the  Product  3 
user  shall  be  as  diagrammed  in  Figures  3-4  (levels  one  to  three),  3-5 
(system  operations  to  level  five),  and  3-6  (system  maintenance  to  level  five). 

3.2.3.1  Design  Aid  Interface  TLSC 

The  Design  Aid  Interface  component  shall  include  all  intermediate  user 
interfaces  and  functions  not  explicitly  reserved  for  one  of  the  other  top  level 
software  components.  It  shall  be  implemented  in  the  Revelation  Data  Base 
Management  System.  Design  Aid  Interface  inputs  and  outputs  shall  be 
diagrammed  in  Figure  3-7.  It  shall  be  divided  into  two  lower  level  software 
components  (LLSCs): 

a.  Interface  LLSC 

The  Interface  LLSC  shall  maintain  and  control  all  necessary 
interfaces  with  the  user,  and  shall  be  responsible  for  transferring 
control  to  the  other  top  level  software  components,  as  required. 
The  Interface  LLSC  shall  be  responsible  for  all  interfaces  between 
the  Design  Aid  Interface  and  other  user-accessible  components. 

b.  Data  Base  Access  LLSC 

The  Data  Base  Access  LLSC  shall  provide  all  routines  necessary 
for  the  access  of  data  base  information  as  specified  by  the  input 
instructions.  AN  interfaces  between  the  Design  Aid  Interface  and 
the  two  data  base  components  shall  be  through  the  Data  Base 
Access  LLSC  only. 
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Figure  3-6.  Detailed  Decision  Pathways  (System  Maintenance) 
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Figure  3-7.  Design  Aid  Interface  Input/Output  Chart 


; 
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3.2.3.1.1  Design  Aid  Interface  Requirements  Allocation 


The  requirements  of  the  Design  Aid  Interface  component  are  divided  into 
three  types  of  operations  and  allocated  to  lower  level  software  components; 
two  of  the  operations  are  assigned  to  one  lower  level  software  component  for 
purposes  of  grouping  commonality  of  functions.  The  allocations  are  as 
follows: 

a.  User  interaction 

User  interaction  shall  consist  of  all  screen  displays  found  within  the 
Design  Aid  Interface  component,  along  with  their  subordinate 
elements,  including  titles  and  menus.  All  user  interaction 
operations  shall  be  allocated  to  a  lower  level  software  component 
designated  as  the  Interface  LLSC. 

b.  User-Accessible  Component  Interaction 

User-accessible  component  interaction  shall  include  those 
functions  necessary  for  the  transfer  of  control  from  the  Design  Aid 
Interface  component  to  the  Analysis,  Search  Process  Record, 
Knowledge  Acquisition  Interface,  and  Training/Help  components. 
All  user-accessible  component  interactions  shall  be  allocated  to  the 
Interface  LLSC. 

c.  Data  Base  Interaction 

Data  base  interaction  shall  include  the  process  of  locating  the 
appropriate  data  base  files  and  displaying  them  to  the  user,  the 
capability  to  interact  with  the  user  interaction  function,  to  control  the 
display  of  Alphanumeric  and  Graphic  Data  Base  information,  the 
taxonomic  structure  necessary  to  translate  the  user-provided 
information  into  a  pointer  to  the  appropriate  data  bases,  the  ability 
to  access  these  data  bases,  and  the  ability  to  display  these  data 
bases  to  the  user.  The  data  base  interaction  shall  be  allocated  to 
the  Data  Base  Access  LLSC.  All  access  from  the  Design  Aid 
Interface  to  the  Alphanumeric  and  Graphics  Data  Bases  shall  occur 
through  the  Data  Base  Access  LLSC. 

3.2.3.1 .2  Interface  LLSC 

The  Interface  LLSC  shall  provide  an  interface  with  both  the  user  and  the 
other  user-accessible  software  components. 


a.  Inputs 


System  control  shall  always  default  to  the  Interface  LLSC.  Inputs 
shall  be  taken  from  the  keyboard  using  function  keys  and  arrow 
keys.  Inputs  shall  be  processed  through  the  BIOS  as  interrupts  to 
the  Product  3  system,  initiating  transfers  of  control  to  the 
appropriate  LLSC.  Other  keyboard  operations  may  be  disabled  in 
this  LLSC,  during  control  default  conditions. 
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b.  Local  Data 

Local  data  shall  consist  of  intermediate  screen  displays  used  for 
directing  the  user  through  the  design  aid  process. 

c.  Processing 
(1)  Control 

The  Interface  LLSC  shall  receive  system  control  upon  startup 
and  system  initialization.  Control  shall  always  be  transferred 
upon  given  user  inputs  to  other  user-accessible  components. 
Control  shall  transfer  automatically  to  the  Data  Base  Access 
LLSC  once  the  user  has  selected  a  design  search  pattern  to  a 
depth  sufficient  to  provide  a  pointer  into  the  appropriate  data 
base  file.  Control  shall  then  be  transferred  back  to  the 
Interface  LLSC  for  display  of  the  file. 
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(2)  Algorithms 

Standard  data  structures  and  manipulation  procedures  shall 
be  required  to  implement  this  LLSC.  The  data  structures, 
readily  available  from  commercial  sources,  shall  take  user 
inputs,  and  select  the  appropriate  display  from  a  tree  structure. 
The  displays  which  are  accessed  via  pointers  shall  then  be 
mapped  into  the  standard  output  device. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

An  Interface  LLSC  user-initiated  error  may  occur  if  the  user 
selects  one  of  the  keys  not  associated  with  a  legitimate  system 
operation,  a  prompt  shall  appear  at  the  bottom  of  the  screen, 
indicating  the  operations  that  are  available  from  that  point  and 
the  actions  necessary  to  implement  those  operations.  Other 
Interface  LLSC  errors  may  occur  if  the  component  control  to 
which  control  is  transferred  does  not  exist  on  the  system.  In 
such  cases,  the  error  shall  cause  an  output  to  the  user, 
indicating  the  source  of  the  error  and  providing  accompanying 
help  instructions. 

(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Interface  LLSC  shall  be  responsible  for  appending  the  screen 
displays  to  the  Search  Process  Record.  The  Interface  LLSC  shall 
receive  a  pointer  from  the  Create  LLSC  in  the  Search  Process 
Record  component  to  the  Search  Process  Record  linked  list  at 
system  initialization.  The  only  function  that  shall  be  performed  by 
the  Interface  LLSC  thereafter  shall  be  to  append  each  screen 
display  to  the  linked  list. 

e.  Limitations 
Not  Applicable 
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f.  Outputs 
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The  Interface  LLSC  shall  have  two  types  of  outputs: 

(1 )  text  files  that  make  up  the  user  interface,  defined  as  direct 
output  to  the  standard  output  device;  and 

(2)  pointers,  defined  by  user  selection  of  system  characteristics, 
that  are  passed  to  the  Data  Base  Access  LLSC  for  selection  of 
the  appropriate  data  file.  These  pointers  shall  be  passed  by 
pointer  address  from  the  Interface  LLSC  to  the  Data  Base 
Access  LLSC. 
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3.2.3.1 .3 

Data  Base  Access 

LLSC 

The  Data  Base  Access  LLSC  shall  select  the  appropriate  data  file  and  pass  it 
back  to  the  Interface  LLSC  for  display. 

a.  Inputs 

The  Data  Base  Access  LLSC  shall  receive  a  pointer  from  the 
Interface  LLSC.  The  pointer  shall  be  passed  by  pointer  address 
from  the  Interface  LLSC  to  the  Data  Base  Access  LLSC. 


! 

I 

No  local  data  shall  be  required  to  execute  the  Data  Base  Access 
I  LLSC.  Pointers  shall  be  passed  from  the  Interface  LLSC  and  data 

J  files  from  the  Alphanumeric  or  Graphics  Data  Bases  shall  be 

returned  for  display. 
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b.  Local  Data 
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c.  Processing 

(1)  Control 


The  Data  Base  Access  LLSC  shall  receive  system  control 
automatically  from  the  Interface  LLSC  once  the  user  has 
indicated  the  desired  design  search  pattern  through  the  user 
interfaces  sufficiently  to  provide  a  pointer  into  the  appropriate 
data  base  file.  When  the  Data  Base  Access  LLSC  has  found 
the  correct  file,  control  shall  then  be  transferred  back  to  the 
Interface  LLSC  for  display  of  the  file. 

(2)  Algorithms 
Not  Applicable. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

Data  Base  Access  LLSC  errors  may  occur  if  the  data  file 
required  by  the  user  does  not  exist  on  the  system.  In  such 
cases,  the  error  shall  cause  an  output  to  the  user  indicating 
the  source  of  the  error  and  providing  accompanying  help 
instructions. 

(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Data  Base  Access  LLSC  is  self-contained  and  uses  no 

elements  from  other  components,  except  for  inputs  as  noted  above. 

e.  Limitations 

Not  Applicable. 

f.  Outputs 

The  Data  Base  Access  LLSC  shall  have  two  types  of  outputs: 


3-44 


(1)  text  files  that  are  extracted  from  the  Alphanumeric  Data  Base, 
and  sent  through  to  the  Interface  LLSC  for  direct  'output  to  the 
standard  output  device;  and 


(2)  bit-mapped  graphics  files  that  are  extracted  from  the  Graphics 
Data  Base  and  sent  through  to  the  Interface  LLSC  for  direct 
output  to  the  standard  output  device. 
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3.2.3.2  Search  Process  riecord  TLSC 

The  Search  Process  Record  shall  create,  maintain,  store,  and  prepare  for 
output  a  list  of  the  data  files  and  displays  viewed  during  the  course  of  a 
design  aid  session  search.  The  functions  performed  by  the  Search  Process 
Record  shall  include  creating  a  search  record,  saving  a  search  record  and 
returning  to  it  later,  editing  a  search  record,  and  printing  a  search  record.  The 
Search  Process  Record  component  shall  be  divided  into  two  LLSCs,  the 
Create  component  and  the  Edit/Print  component.  The  Create  LLSC  shall 
include  the  data  structures  and  algorithms  necessary  to  create  and  append  to 
the  list  of  displays.  The  Edit/Print  LLSC  shall  permit  the  user  to  manipulate 
an  already-existing  search  list  and  to  save  and/or  print  out  the  appended 
results  of  a  search  process.  The  Search  Process  Record  inputs  and  outputs 
shall  be  as  diagrammed  in  Figure  3-8. 

3.2.3.2.1  Search  Process  Record  Requirements  Allocation 

The  allocation  of  the  creating  function  shall  be  considered  separate  from  the 
other  Search  Process  Record  functions,  to  permit  records  to  be  globally 
available  to  all  user-accessible  components  and  allow  updating  to  occur. 
Therefore,  the  creating  and  maintaining  functions  shall  be  allocated  to  a 
lower  level  software  component  designated  as  the  Create  LLSC.  The 
functions  of  saving  and  returning,  editing,  and  printing  are  components  of  a 
standard  text  editor  and  shall  be  allocated  to  a  lower  level  software 
component  designated  as  the  Edit/Print  LLSC. 
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3.2.3. 2.2  Create  LLSC 


The  Create  LLSC  shall  generate  the  data  structures  necessary  to  build  the 
Search  Process  Record.  These  actions  shall  occur  automatically  at  system 
initialization.  Once  the  data  structures  are  created,  each  screen  shall  be 
appended  to  the  linked  list  structure  from  the  Design  Aid  Interface 
component,  to  eliminate  the  need  for  an  additional  transfer  of  control  back  to 
the  Search  Process  Record  component  to  accomplish  this  function.  The 
linked  list  shall  then  be  passed  back  to  the  Design  Aid  Interface  at  system 
initialization,  where  it  shall  be  maintained  by  the  Design  Aid  Interface 
component  until  user  inputs  request  a  transfer  back  to  the  Search  Process 
Record. 

a.  Inputs 

Not  Applicable. 

b.  Local  Data 

Those  variables  necessary  to  create  the  list  data  structure  comprise 

the  Create  LLSC  local  data. 

c.  Processing 

(1)  Control 

The  Create  LLSC  shall  receive  control  automatically  as  a  part 
of  Product  3  system  initialization  at  startup.  After  creating  and 
initialization  of  the  Create  LLSC's  own  data  structures,  control 
shall  automatically  return  to  the  Design  Aid  Interface 
component. 

(2)  Algorithms 

Algorithms  utilized  in  the  Create  LLSC,  consist  of  those 
variables  necessary  to  create  the  list  data  structure. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

A  Create  LLSC  external  error  may  occur  when  a  file 
necessary  to  execute  the  Create  function  is  not  available  at 
startup.  The  system  will  not  boot,  and  an  error  message  shall 
be  transmitted  to  the  user,  stating  the  reason  for  the  error  and 
providing  accompanying  help  instructions. 
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(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 
Not  Applicable. 

e.  Limitations 
Not  Applicable. 

L  Outputs 

The  Create  LLSC  shall  provide  the  Design  Aid  Interface 
component  with  a  linked  list  data  structure  onto  which  all  screen 
displays  are  appended.  This  list  shall  be  constructed  with  pointers 
to  allocate  memory  dynamically,  a  feature  that  also  permits  the 
output  to  be  passed  out  of  the  LLSC  via  a  pointer  address. 
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3.2.3.2.3  Edit/Print  LLSC 

The  Edit/Print  LLSC  shall  provide  a  text  and  screen  edit  capability  for  the 
Search  Process  Record  and  shall  enable  the  user  to  direct  the  output  of  the 
Search  Process  to  system  accessible  media.  This  capability  shall  permit  the 
editing  of  a  design  search  to  the  requirements  necessitated  by  the  design 
project  and  prepare  the  text  and  graphics  for  output. 

a.  Inputs 

To  enable  edits  of  the  Search  Process  Record,  the  record  itself 
shall  be  passed  into  the  Edit/Print  LLSC.  A  pointer  to  the  head  of 
the  list  shall  be  passed  as  a  parameter. 
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b.  Local  Data 

(1 )  Edit  Process 

During  the  edit  process,  a  temporary  file  consisting  of  the 
document  being  edited  shall  be  created.  To  save  main 
memory  in  the  case  of  a  large  search  process  record,  this  file 
shall  be  maintained  on  disk,  at  the  expense  of  slower  access 
time.  When  editing  is  completed,  this  file  shall  either: 

(a)  Replace  the  original  unedited  search  process  record, 
which  shall  then  be  saved  to  disk;  or 

(b)  Be  saved  to  disk  while  maintaining  the  original  search 
process  record  for  further  design  search  activities,  or  for 
later  revising. 

(2)  Print  Process 

During  the  print  process,  a  temporary  print  file  shall  be  created 
from  the  search  process  record.  This  print  file  will  be  created 
on  disk  rather  than  in  main  memory  to  accommodate  large 
search  process  records.  When  printing  is  complete,  this 
temporary  file  shall  be  automatically  deleted  from  disk. 

c.  Processing 
(1 )  Control 

Control  shall  automatically  default  into  the  Edit/Print  LLSC 
upon  entry  into  the  Search  Process  Record  component. 
Control  shall  be  retained  by  the  Edit/Print  LLSC  at  all  times 
while  manipulating  the  Search  Process  Record  data.  Upon 
completion  of  Edit/Print  operations,  control  shall  be  returned  to 
the  Design  Aid  Interface  component. 
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(2)  Algorithms 


The  Edit/Print  LLSC  shall  be  a  standard  text  editor,  with  the 
ability  to  cut  and  paste  whole  graphic  images.  The  Edit/Print 
LLSC  shall  implement  algorithms  for  the  modification, 
copying,  cutting,  and  pasting  of  all  files  and  individual  parts  of 
text  files,  and  provide  for  access  to  the  system  print  driver  to 
print  the  resulting  file. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

Four  types  of  Edit/Print  LLSC  errors  may  occur: 

(a)  User  requests  to  edit/print  empty  search  process  records. 

User  requests  to  edit/print  empty  search  process  records 
shall  result  in  an  error  message  being  transmitted  to  the 
user,  indicating  the  source  of  the  error  and  directing  the 
user  to  the  option  of  selecting  existing  disk  files. 

(b)  User  request  to  edit  portions  of  a  graphics  file. 

User  requests  to  edit  portions  of  a  graphics  file  shall 
result  in  an  error  message  being  transmitted  to  the  user, 
indicating  the  source  of  the  error. 

(c)  User  requests  to  save  edited  search  process  records  to 
disk. 

User  requests  to  save  edited  search  process  records  to 
cfisk,  when  the  lack  of  disk  space  will  not  permit,  shall 
result  in  an  error  message  being  transmitted  to  the  user, 
indicating  the  source  of  the  error  and  directing  the  user  to 
the  option  of  saving  the  output  on  a  floppy  disk. 

(d)  User  requests  to  print  graphics  outputs. 

User  requests  to  print  graphics  outputs,  when  the  proper 
printer  or  printer  drive  is  not  available,  shall  result  in  an 
error  message  being  transmitted  to  the  user,  indicating 
the  source  of  the  error  and  directing  the  user  to  the  option 
of  saving  the  output  on  a  floppy  disk. 


* 
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(5)  Data  Conversion 
Not  Applicable. 


(6)  Communication  Interfaces 

The  external  interface  with  the  Edit/Print  LLSC  shall  be  the 
printer  driver  and  printer.  The  LLSC  shall  have  the  capability 
to  output  to  a  laser  or  dot-matrix  printer,  given  the  appropriate 
printer  driver. 

d.  Utilization  of  Other  Elements 

The  Edit/Print  LLSC  shall  be  self-contained  in  its  functions  and 
shall  not  require  utilization  of  elements  outside  of  its  designated 
storage  and  memory  space.  The  Search  Process  Record  itself 
shall  exist  in  memory  and  shall  be  accessible  from  the  Edit/Print 
LLSC. 

e.  Limitations 

The  size  of  the  Search  Process  Record  shall  be  limited  by  the 
amount  of  memory  available  in  the  hardware  system.  If  memory 
reserves  during  a  design  search  fall  below  10%  of  main  memory,  a 
warning  message  shall  be  issued,  accompanied  by  appropriate 
help  instructions. 

f.  Outputs 

The  Edit/Print  LLSC  shall  output  its  edited  file  into  one  of  two  output 
devices:  the  printer  or  the  disk.  The  printer  shall  be  the  standard 
output  device,  and  control  shall  default  to  hard  copy  output.  The 
user  shall  be  able  to  set  the  output  device  to  be  the  hard  disk  or  a 
floppy  disk,  and  save  the  file  to  one  of  these  media.  The  edited 
search  process  record  may  also  be  returned  to  the  Design  Aid 
Interface  for  further  design  search  activities,  via  pointer  address. 
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3. 2.3.3  Analysis  TLSC 


The  Analysis  component  shall  provide  user-defined  data  manipulation 
functions  to  permit  the  examination  of  data.  Analysis  inputs  and  outputs  shall 
be  as  diagrammed  in  Figure  3-9. 

3.2.3.3.1  Requirements  Atlocation 

The  requirements  of  the  Analysis  component  shall  be  divided  into  three  sets 
of  operations: 

a.  Descriptive  Statistics 

Descriptive  statistics  shall  provide  the  user  with  the  capability  to 
relate  human  parametric  data  to  hardware  design.  All  standard 
statistical  operations  shall  be  allocated  to  a  lower  level  software 
design  component  designated  as  the  Descriptive  Statistics  LLSC. 

b.  Transformations 

Transformation  operations  shall  provide  the  user  with  the  capability 
to  derive  new  measures  of  human  performance.  All  transformation 
operations  shall  be  allocated  to  a  lower  level  software  design 
component  designated  as  the  Transformations  LLSC. 

c.  Correlations/Predictions 

Correlation/Prediction  operations  shall  provide  the  user  with  the 
capability  to  perform  correlations  and/or  predictions  of  trends,  or 
extrapolations  of  data.  All  correlation  and  prediction  operations 
shall  be  allocated  to  a  lower  level  software  design  component 
designated  as  the  Correlations/Predictions  LLSC. 

3. 2. 3. 3. 2.  Descriptive  Statistics  LLSC 

The  Descriptive  Statistics  LLSC  shall  provide  the  user  with  the  capability  to 
generate  descriptive  statistics  on  information  stored  in  the  Alphanumeric  Data 
Base.  As  a  minimum,  the  following  descriptive  statistic  operations  shall  be 
included: 


•  mean 

•  median 

•  mode 

•  variance 
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•  standard  deviation 

•  standard  error  of  the  mean 

•  rimmed  mean 

•  first  and  third  quantile 

•  fifth  and  ninety-fifth  percentile 

a.  Inputs 

To  activate  the  Descriptive  Statistics  component,  the  user  shall  be 
required  to  input  the  name  of  the  data  file  or  files  to  be  analyzed, 
using  the  data  file  name  and  the  redirection  operator.  When 
multiple  variables  exist  within  a  single  data  file,  the  user  shall  have 
the  option  to  specify  a  specific  variable  or  set  of  variables  within 
that  file  for  evaluation.  The  default  operation  shall  be  evaluation 
on  all  variables  within  the  file. 


text  file  data  input 

file  name 

Alphanumeric 

+  optional  variable(s) 

Data  Base 

b.  Local  Data 


The  Descriptive  Statistics  local  data  shall  include: 

(1 )  All  manipulation  of  raw  data  into  descriptions  of  central 
tendency  and  dispersion. 

(2)  AH  intermediate  products,  including  but  not  limited  to  matrices, 
summations,  and  orderings. 

(3)  All  output  products, 
c.  Processing 

(1)  Control 

Control  shall  be  transferred  to  the  Descriptive  Statistics  LLSC 
upon  call  from  the  Design  Aid  Interface  for  descriptive  statistics 
operations.  Control  shall  remain  in  this  component  until  the 
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operation  processing  is  complete,  at  which  time  control  shall 
be  transferred  back  to  the  Design  Aid  Interface.  * 

(2)  Algorithms 

Standard  algorithms  shall  be  used  in  the  creation  of  all 
statistical  products.  As  all  algorithms  to  be  used  in  the 
Descriptive  Statistics  LLSC  are  straightforward  and  universal, 
they  shall  be  cited  f:om  commercially  available  sources. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

The  Descriptive  Statistics  LLSC  may  have  two  types  of  errors: 

(a)  Errors  that  occur  when  the  user  requests  passage  of  a 
nonexistent  data  file  or  a  nondata  file  to  the  component. 
For  this  type  of  error,  execution  shall  be  interrupted  and 
an  error  message  stating  the  probable  cause  of  the  error 
shall  be  transmitted  to  the  user,  along  with  associated 
help  functions. 

b.  Errors  that  occur  when  the  user  requests  passage  of 
inappropriate  data  to  the  component  (e.g.,  if  the  user 
requests  descriptive  statistics  on  nominal  or  ordinal  data, 
such  as  telephone  numbers),  if  meaningless  results  are 
received,  the  user  can  request  help  on  meaningless  data 
outputs,  which  would  indicate  the  probable  source  of  the 
error. 

(5)  Data  Conversion 

All  alphanumeric  data  shall  remain  in  the  same  form  while  in 
the  Descriptive  Statistics  LLSC.  All  operations  shall  be 
conducted  as  floating  point. 

(6)  Communication  Interfaces 
Not  Applicable 

d.  Utilization  of  Other  Elements 

The  Descriptive  Statistics  component  is  self-contained  and  shall 

not  require  utilization  of  elements  outside  of  its  designated  storage 
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and  memory  space,  except  for  the  input  file  or  *•  as  from  the 
Alphanumeric  Data  Base. 


e.  Limitations 
Not  Applicable. 

f.  Outputs 

The  Descriptive  Statistics  LLSC  shall  output  the  results  of  its 
analysis  directly  to  the  Design  Aid  Interface  in  the  form  of  ASCII 
alphanumeric  data  and  stored  in  a  temporary  file  for  display  to  the 
user.  The  output  shall  be  appended  to  the  Search  Process  Record 
and  deleted  upon  completion  of  the  design  aid  session.  The  output 
may  be  saved  for  insertion  into  the  Alphanumeric  Data  Base  at  a 
later  time  or  saved  as  a  Search  Process  Record  file  in  accordance 
with  user  instructions. 
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3.2.3.3.3.  Transformations  LLSC 

The  Transformations  LLSC  shall  provide  the  capability  to  manipulate  data 
from  the  Alphanumeric  Data  Base  according  to  a  set  of  predefined  and  user- 
defined  transformations  and  to  prepare  it  for  possible  further  evaluation. 

a.  Inputs 

To  activate  the  Transformations  LLSC,  the  user  shall  be  required  to 
input  the  name  of  the  data  file  to  be  analyzed,  using  the  data  file 
name  and  the  redirection  operator.  When  multiple  variables  exist 
within  a  single  data  file,  the  user  shall  have  the  option  of  specifying 
a  specific  variable  or  variables  within  that  file  for  evaluation.  The 
default  operation  shall  be  evaluation  on  all  variables  within  the  file. 
Provision  shall  also  be  made  for  the  construction  and  use  of  user- 
defined  transformations.  The  user  shall  be  given  a  menu  of 
predefined  transformations  that  shall  include  the  following: 


logarithmic 


•  exponential 

•  powers 


•  roots 

•  straight  lines 
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b.  Local  Data 

The  Transformations  LLSC  local  data  shall  include: 

(1 )  All  manipulation  of  raw  data  into  descriptions  of  transforms. 

(2)  All  intermediate  products,  including  but  not  limited  to  matrices, 
summations,  and  orderings. 

(3)  All  output  products. 

c.  Processing 

(1)  Control 

Control  shall  be  transferred  to  the  Transformations  LLSC  upon 
call  from  the  Design  Aid  Interface  for  transformation 
processing  operations.  Control  shall  remain  in  the 
Transformations  LLSC  until  the  transformation  processing  is 
complete,  at  which  time  control  shall  be  transferred  back  to  the 
Design  Aid  Interface. 

(2)  Algorithms 

Standard  algorithms  shall  be  used  in  the  creation  of  all 
statistical  products.  As  all  algorithms  to  be  used  in  the 
Transformations  component  are  straightforward  and  universal, 
they  shall  be  cited  from  commercially  available  sources. 
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(3)  Special  Control  Features 
Not  Applicable 

(4)  Error  Handling 

The  Transformations  LLSC  may  have  two  types  of  errors: 

(a)  Errors  that  occur  when  the  user  requests  passage  of  a 
nonexistent  data  file  or  a  nondata  file  to  the  component. 
For  this  type  of  error,  execution  shall  be  interrupted  and 
an  error  message  stating  the  probable  cause  of  the  error 
shall  be  transmitted  to  the  user,  along  with  associated 
help  instructions. 

(b)  Errors  that  occur  when  the  user  requests  passage  of 
inappropriate  data  to  the  component  (e.g.,  if  the  user 
requests  descriptive  statistics  on  nominal  or  ordinal  data, 
such  as  telephone  numbers).  If  meaningless  results  are 
received,  the  user  can  request  help  on  meaningless  data 
outputs,  which  would  indicate  the  probable  source  of  the 
error. 

(5)  Data  Conversion 

All  data  shall  remain  in  the  same  form  while  in  the 
Transformations  LLSC.  All  operations  shall  be  conducted  as 
floating  point. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Transformations  LLSC  is  self-contained  and  shall  not  require 
utilization  of  elements  outside  of  its  designated  storage  and 
memory  space,  except  for  the  input  file  or  files  from  the 
Alphanumeric  Data  Base. 

e.  Limitations 


Not  Applicable. 


f.  Outputs 


The  Transformations  LLSC  shall  output  the  results  o‘f  its  analysis 
directly  to  the  Design  Aid  Interface  in  the  form  of  ASCII 
alphanumeric  data  and  stored  in  a  temporary  file  for  display  to  the 
user.  The  output  shall  be  appended  to  the  Search  Process  Record 
and  deleted  upon  completion  of  the  design  aid  session.  The  output 
may  be  saved  for  insertion  into  the  Alphanumeric  Data  Base  at  a 
later  time  or  saved  as  a  Search  Process  Record  file  in  accordance 
with  user  instructions. 
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3.2.3.3.4  Correlation/Predictions  LLSC 

The  Correlation/Predictions  LLSC  shall  provide  the  capability  for  the  user  to 
investigate  the  relationships  between  variables,  and  to  use  those 
relationships  to  make  extrapolations  or  predictions  based  on  those 
relationships.  The  user  shall  have  the  capability  to  select,  one  at  a  time,  the 
following  standard  statistical  procedures: 

•  Pearson's  (r)  correlation 

•  Spearman’s  (rho)  correlation 

•  simple  and  multiple  least  squares  regression 

•  moving  average  time  series  models 

•  autoregressive  time  series  models 

•  ARIMA  time  series  models 
a.  Inputs 

To  activate  the  Correlations/Predictions  LLSC,  the  user  shall  be 
required  to  input  the  name  of  the  data  file  to  be  analyzed,  using  the 
data  file  name  and  the  redirection  operator.  When  multiple 
variables  exist  within  a  single  data  file,  the  user  shall  have  the 
option  of  specifying  a  specific  variable  or  variables  within  that  file 
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for  evaluation.  The  default  operation  shall  be  evaluation  on  all 
variables  within  the  file. 
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b.  Local  Data 

The  Correlations/Predictions  LLSC  local  data  shall  include: 

(1 )  All  manipulation  of  raw  data  into  descriptions  of  transforms. 

(2)  All  intermediate  products,  including  but  not  limited  to  matrices, 
summations,  and  orderings. 

(3)  All  output  products. 

c.  Processing 

(1)  Control 

Control  shall  be  transferred  to  the  Correlations/Predictions 
LLSC  upon  call  from  the  Design  Aid  Interface  for 
transformation  processing  operations.  Control  shall  remain  in 
this  component  until  the  transformation  processing  is 
complete,  at  which  time  control  shall  be  transferred  back  to  the 
Design  Aid  Interface. 

(2)  Algorithms 

Standard  algorithms  shall  be  used  in  the  creation  of  all 
statistical  products.  As  all  algorithms  to  be  used  in  the 
Correlations/Predictions  LLSC  are  straightforward  and 
universal,  they  shall  be  cited  from  commercially  available 
sources. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

The  Correlation/Predictions  LLSC  may  have  two  types  of 
errors: 
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(a)  Errors  that  occur  when  the  user  requests  passage  of  a 
nonexistent  data  file  or  a  nondata  file  to  the  component. 
For  this  type  of  error,  execution  shall  be  interrupted  and 
an  error  message  stating  the  probable  cause  of  the  error 
shall  be  transmitted  to  the  user,  along  with  associated 
help  functions. 

(b)  Errors  that  occur  when  the  user  requests  passage  of 
inappropriate  data  to  the  component  (e.g.,  if  the  user 
requests  descriptive  statistics  on  nominal  or  ordinal  data, 
such  as  telephone  numbers).  If  meaningless  results  are 
received,  the  user  can  request  help  on  meaningless  data 
outputs,  which  would  indicate  the  probable  source  of  the 
error. 

(5)  Data  Conversion 

All  data  shall  remain  in  the  same  form  while  in  the 
Correlations/Predictions  LLSC.  All  operations  shall  be 
conducted  as  floating  point. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Correlations/Predictions  LLSC  is  self-contained  and  shall  not 
require  utilization  of  elements  outside  of  its  designated  storage  and 
memory  space. 

e.  Limitations 

The  Transformations  LLSC  shall  accept  both  formatted  and 
unformatted  data  f'les  as  input. 

f.  Outputs 

The  Correlations/Predictions  LLSC  shall  output  the  results  of  its 
analysis  directly  to  the  Design  Aid  Interface  in  the  form  of  ASCII 
alphanumeric  data  and  stored  in  a  temporary  file  for  display  to  the 
user.  The  output  shall  be  appended  to  the  Search  Process  Record 
and  deleted  upon  completion  of  the  design  aid  session.  The  output 
may  be  saved  for  insertion  into  the  Alphanumeric  Data  Base  at  a 
later  time  or  saved  as  a  Search  Process  Record  file  in  accordance 
with  user  instructions. 
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3. 2.3.4  Knowledge  Acquisition  Interface  TLSC 

The  Knowledge  Acquisition  Interface  shall  provide  the  Product  3  software 
system  with  the  means  of  adding  new  information  and  modifying  old 
information  in  the  data  files.  This  component  shall  be  accessible  from  the 
Design  Aid  Interface  component  only.  Component  inputs  and  outputs  shall 
be  as  diagrammed  in  Figure  3-10.  The  Knowledge  Acquisition  Interface 
TLSC  shall  be  divided  into  two  lower  level  software  components  (LLSCs): 

a.  Manual  Update  LLSC 

The  Manual  Update  LLSC  shall  provide  the  capability  for  the  user 
to  make  discrete  modifications  in  individual  data  files  as  new 
information  becomes  available.  It  shall  not  have  the  capability  to 
add  or  modify  existing  graphic  data  files.  The  Manual  Update 
LLSC  shall  have  the  capability  to  guide  the  user  to  the  desired  data 
file  or  set  of  files  through  the  use  of  a  taxonomy  similar  to  that  used 
in  the  design  search  operations.  This  LLSC  shall  provide  for  a 
hierarchical  ordering  of  human  characteristics,  to  provide  the  user 
with  the  capability  to  select  progressively  more  detailed 
characteristics  until  a  single  file  or  a  maximum  subset  of  three  files 
have  been  selected  as  the  most  likely  candidates  for  the  input 
and/or  deletion  of  data.  However,  the  system  shall  also  provide  the 
capability  for  a  user  to  select  a  file  directly  and  enter  the  desired 
changes,  if  the  name  of  the  file  to  be  updated  is  known. 

b.  Automated  Update  LLSC. 

The  Automated  Update  LLSC  shall  permit  the  user  to  enter  entire 
updated  or  new  files  into  both  the  Alphanumeric  and  Graphics  Data 
Bases.  These  files  may  be  located  on  either  a  floppy  disk  or 
Bernoulli  removable  hard  disk.  This  component  shall  also  connect 
the  data  structures  that  supply  the  links  between  the  design  search 
taxonomy  and  the  individual  data  files. 


| 
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Figure  3-10.  Knowledge  Acquisition  Interface  Input/Output  Chart 
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3. 2. 3. 4.1  Knowledge  Acquisition  Interface  Requirements 
Allocation 

The  Knowledge  Acquisition  Interface  shall  address  the  following 
requirements:  file  selection  and  file  modification.  These  functions  shall  also 
exist  in  two  different  states  of  operation:  manual,  in  which  the  user  selects 
and  updates  by  direct  input  from  the  keyboard;  and  automatic,  where 
selection  and  updating  is  done  by  a  previously-prepared  floppy  disk  without 
input  from  the  keyboard.  These  requirements  shall  be  fulfilled  by  two  lower 
level  components:  the  Manual  Update  LLSC  and  the  Automatic  Update 
LLSC. 

3. 2.3. 4. 2  Manual  Update  LLSC 

The  Manual  Update  LLSC  shall  permit  the  user  to  make  discrete 
modifications  in  individual  data  files  as  new  information  becomes  available. 

a.  Inputs 

The  Manual  Update  LLSC  shall  have  the  capability  to  accept 
instructions  to  search,  identify,  and  select  desired  files  through  the 
use  of  the  Product  3  workstation  keyboard.  These  inputs  shall 
accomplish  two  purposes: 

(1 )  Permit  the  user  to  locate  and  open  a  text  data  file. 

(2)  Permit  the  user  to  modify  the  opened  file. 
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b.  Local  Data 

No  local  data  shall  be  created  in  the  Manual  Update  LLSC  except 
for  those  variables  necessary  to  carry  out  the  text  editing  function. 
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c.  Processing 

(1)  Control 

Control  shall  automatically  default  into  the  Manual  Update 
LLSC  upon  entrance  into  the  Knowledge  Acquisition  Interface 
component.  The  component  shall  provide  the  user  with  the 
capability  to  continue  with  the  manual  updating  process,  or 
transfer  into  the  Automatic  Update  LLSC.  All  text  data  file 
location,  selection,  opening,  closing,  and  text  editing  shall 
occur  from  within  the  Manual  Update  LLSC.  The  component 
shall  access  data  base  files  belonging  to  the  Alphanumeric 
Data  Base  component. 

(2)  Algorithms 

Manual  Update  LLSC  algorithms  consist  of  readily  available 
commercial  structures  for  standard  file  open,  file  close,  and 
text  editing  functions  used  in  this  component. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

The  Manual  Update  LLSC  may  have  two  types  of  errors 
generated: 

(a)  Requesting  nonexisting  data  file  to  be  opened.  The 
system  shall  transmit  an  error  message  for  display  to  the 
user,  indicating  the  probable  cause(s).  The  error 
message  shall  be  accompanied  by  related  Help 
instructions. 

(b)  Inadvertent  update  of  incorrect  files.  No  error  message 
will  be  available  to  signal  this  type  of  error;  however,  the 
system  shall  automatically  provide  the  user  with  the 
opportunity  to  review  the  edits  prior  to  saving  the  input 
data. 

(c)  Data  Conversion 
Not  Applicable 

(6)  Communication  Interfaces 
Not  Applicable. 
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d.  Utilization  of  Other  Elements 

The  Manual  Update  LLSC  shall  make  use  of  the  Alphanumeric 
Data  Base  component  in  the  update  process.  If  a  new  text  data  file 
is  being  added  by  the  manual  update  method,  this  component  shall 
also  access  the  Design  Aid  Interface  component  in  order  to  form  a 
new  taxonomic  pathway  to  that  file,  so  that  it  can  be  accessed  and 
displayed  to  the  user  as  required. 

e.  Limitations 
Not  Applicable. 

f.  Outputs 


The  Manual  Update  LLSC  outputs  only  textual  information  and 
only  to  the  standard  output  device. 
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3.2.3.4.3  Automated  Update  LLSC 


The  Automated  Update  LLSC  shall  provide  the  system  with  the  capability  to 
make  major  modifications  or  add  entirely  new  text  files  to  the  Alphanumeric 
Data  Base,  or  to  add  bit-mapped  graphics  files  to  the  Graphics  Data  Base. 
These  updates  shall  be  done  by  way  of  a  floppy  disk  or  Bernoulli  removable 
hard  disk.  Disks  used  for  this  purpose  shall  contain  the  text  and  Graphics 
Data  Base  files  for  updating,  and  the  pathways  from  the  Design  Aid  Interface 
to  the  new  files  or  modified  files,  if  necessary. 

a.  Inputs 

.  There  shall  be  four  types  of  inputs  into  the  Automatic  Update  LLSC; 
instructions  from  the  user  to  start  the  automatic  update  process,  text 
files  for  inclusion  in  the  Alphanumeric  Data  Base  component, 
graphics  files  for  inclusion  in  the  Graphics  Data  Base  component, 
and  new  or  amended  pathways  to  these  files  for  inclusion  in  the 
Design  Aid  Interface  component. 
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b.  Local  Data 
Not  Applicable. 

c.  Processing 

(1 )  Control 

Control  shall  automatically  default  into  the  Manual  Update 
LLSC  upon  entrance  into  the  Knowledge  Acquisition  Interface 
component.  The  Manual  Update  LLSC  shall  provide  the  user 
with  the.  capability  to  transfer  into  the  Automatic  Update 
component.  In  the  Automatic  Update  option,  the  user  shall 
insert  the  floppy  or  Bernoulli  disk  containing  the  update  files 
and  pathways.  The  Automatic  Update  LLSC  shall  access 
data  base  files  belonging  to  the  Alphanumeric  and  Graphics 
Data  Base  components.  Once  all  automatic  file  modifications 
and  new  pathway  constructions  are  completed,  the  Automatic 
Update  LLSC  shall  automatically  transfer  control  back  to  the 
Manual  Update  LLSC  for  further  update  exercises  or  for  exit 
from  the  Knowledge  Acquisition  Interface. 

(2)  Algorithms 

Not  Applicable. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 

The  Automated  Update  LLSC  may  have  two  types  of  errors 
generated: 

a.  Insufficient  storage  space  on  the  mass  storage  device  to 
include  the  new  or  updated  data  files.  The  user  shall 
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receive  a  message  that  insufficient  space  exists  for  that 
operation. 


b.  Unauthorized  file  name  changes  may  result  in  the 
creation  of  two  different  files,  the  new  and  the  old,  each 
with  separate  taxonomic  pathways.  This  shall  not  cause 
a  system  error,  but  may  present  redundant  design 
information  to  the  user.  No  error  message  will  be 
available  to  signal  this  type  of  error;  however,  repetitions 
of  output  will  enable  the  user  to  recognize  this  situation. 

(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Automatic  Update  LLSC  shall  make  use  of  the  Alphanumeric 
and  Graphics  Data  Base  components  in  the  update  process.  If  a 
new  text  data  file  is  being  added  by  the  manual  update  method, 
this  LLSC  shall  also  access  the  Design  Aid  Interface  component  in 
order  to  form  a  new  taxonomic  pathway  to  that  file,  so  that  it  can  be 
accessed  and  displayed  to  the  user  as  required. 

e.  Limitations 
Not  Applicable. 

f.  Outputs 

The  Automatic  Update  LLSC  outputs  only  textual  information  and 
only  to  the  standard  output  device.  This  textual  information  shall 
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3.2.3.S  Training/Help  TLSC 

The  Training/Help  TLSC  is  divided  into  two  Lower  Level  Software 
Components  (LLSCs):  the  Training  LLSC  and  the  Help  LLSC.  Component 
inputs  and  outputs  shall  be  as  diagrammed  in  Figure  3-11. 

3.2.3.5.1  Training/Help  Requirements  Allocation 

The  requirements  of  the  Training/Help  TLSC  can  be  divided  into  two  types  of 
operations:  the  requirement  to  introduce  a  new  user  to  the  functionality  of 
MANPRINT  Product  3,  and  the  requirement  to  assist  an  inexperienced  or 
casual  user  who  may  have  an  understanding  of  Product  3  functionality,  but 
may  not  be  sufficiently  familiar  with  the  software  system  to  independently 
direct  a  specific  design  search  process.  The  first  requirement  will  fall  in  the 
category  of  training  in  the  philosophy  and  general  approach  of  the  software 
system,  while  the  second  requirement  will  go  beyond  initial  training  into 
assistance  (help)  for  specific  situations  in  the  design  search  process. 
Therefore,  these  primary  functions  shall  be  divided  into  two  Lower  Level 
Software  Components. 

3.2.3.5.2  Training  LLSC 

The  Training  LLSC  shall  provide  the  use'r  with  an  initial  orientation  into  the 
functionality  and  procedures  of  the  Product  3  software  system. 

a.  Inputs 

Entry  into  the  Training  LLSC  shall  cause  the  system  to  begin  an 
automatic  simulated  design  search.  This  sample  design  search 
shall  be  conducted  step  by  step  to  permit  the  user  to  observe  the 
process  and  note  the  functions  available.  In  addition,  the  user  shall 
be  able  to: 

(1 )  Start  the  sample  design  search, 

(2)  Pause  at  any  part  of  the  sample  design  search  to  more  closely 
examine  a  feature, 

(3)  Abort  the  sample  design  search  in  progress,  and 

(4)  Leave  the  Training  component  and  return  to  the  Design  Aid 
Interface  component. 
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b.  Local  Data 


Training  LLSC  local  data  shall  consist  of  programmed  instructions 
for  the  conduct  of  the  sample  design  search.  These  instructions 
shall  be  written  in  the  Revelation  terminal  control  language  so  that 
the  instructions  can  access  and  direct  the  other  components  in  the 
execution  of  the  sample  search. 

c.  Processing 

(1)  Control 

The  Training  LLSC  shall  receive  system  control  upon  manual 
transfer  by  the  user  from  the  Design  Aid  Interface  TLSC. 
Control  shall  be  maintained  by  this  LLSC  throughout  the 
sample  design  search,  although  it  calls  several  of  the  other 
TLSCs  in  order  to  execute  the  simulated  search. 

(2)  Algorithms 

Standard  data  structures  and  manipulation  procedures  shall 
be  required  to  implement  this  LLSC.  The  standard  data 
structures  shall  take  user  keystrokes  as  input,  and  select  the 
appropriate  display  from  a  tree  structure  (Figure  3-5),  in  which 
the  displays  are  accessed  via  pointers.  The  display  shall  then 
be  mapped  into  the  standard  output  device. 

(3)  Special  Control  Features 
Not  Applicable. 
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(4)  Error  Handling 

Only  one  user-initiated  error  is  possible  from  the  Training 
LLSC.  Given  user  selection  of  a  key  not  associated  with  a 
legitimate  system  operation,  a  prompt  shall  appear  at  the 
bottom  of  the  screen,  indicating  operations  available  from  that 
point  and  the  actions  necessary  to  implement  those 
operations.  Internal  errors  may  occur  if  the  Training  LLSC 
attempts  to  transfer  control  to  a  non-existent  component.  For 
such  errors,  an  error  message  shall  be  output,  indicating  the 
source  of  the  error  and  providing  accompanying  help 
instructions. 

(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Training  LLSC  shall  call  on  the  Interface  LLSC  in  the 
accomplishment  of  the  conduct  of  a  sample  design  aid  session. 
Through  the  Interface  LLSC,  it  shall  have  the  capability  to  cal!  the 
Search  Process  Record  and  Analysis  components  directly,  and 
Alphanumeric  and  Graphics  Data  Base  components  indirectly 
through  the  Data  Access  LLSC. 

e.  Limitations 

Not  Applicable. 

f.  Outputs 

Outputs  from  the  Training  LLSC  shall  consist  of  the  series  of  screen 
displays  that  constitute  the  sample  design  aid  session.  These 
screen  displays  shall  be  returned  directly  to  the  user  via  the 
standard  output  device  and  are  not  saved,  except  in  the  search 
process  record  constructed  during  the  sample  session.  The  search 
process  record  constructed  during  a  training  session  shall  be 
deleted  prior  to  leaving  the  Training  LLSC. 
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Method  Destination 

screen  displays 

sample  design  search 

direct  output  user 

3. 2. 3. 5. 3  Help  LLSC 

The  Help  LLSC  shall  provide  the  user  with  situational  prompts  and 
assistance  at  all  decision  points  in  a  design  search. 


a.  Inputs 


The  Help  LLSC  shall  accept  two  user  inputs,  both  function  keys 
input  by  the  user,  to  enable  the  user  to  enter  and  exit  the  help  files. 


Inout 

Puroose  . 

. Source 

Menu  Item  1 

enter  HELP 

direct  input 

user 

Menu  Item  2 

exit  HELP 

direct  input 

user 

b.  Local  Data 

The  Help  LLSC  local  data  shall  consist  of  textual  data  that 
comprise  the  text  of  the  help  messages. 


c.  Processing 

(1)  Control 

Given  a  user  request  for  a  help  screen,  the  Help  LLSC  shall 
receive  system  control  automatically  from  the  Interface  LLSC. 
Once  the  user  has  completed  with  the  help  message,  control 
shall  be  transferred  back  to  the  Design  Aid  Interface. 

(2)  Algorithms 
Not  Applicable. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 
Not  Applicable. 
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(5)  Data  Conversion 
Not  Applicable. 


I 

l  * 


(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Help  LLSC  is  self-contained  and  uses  no  elements  from  other 
components,  except  for  inputs  as  noted  above. 

e.  Limitations 
Not  Applicable. 

f.  Outputs 

The  Help  LLSC  shall  output  textual  data  to  the  standard  output 
device.  This  textual  data  represents  the  contents  of  the  situational 
assistance  provided  to  the  user  during  the  course  of  a  design 
search. 


ISffiHI 

Destination 

text  sere  ms 

provide  assistance 

direct  output 

Design  Aid  Interface 

3. 2.3.6  Alphanumeric  Data  Base  TLSC 


The  Alphanumeric  Data  Base  component  shall  consist  of  all  prestored  text 
and  numeric  files  containing  data  on  significant  soldier  characteristics. 
These  files  shall  be  created  using  text  editors  or  data  file  transfer 
mechanisms,  and  stored  on  the  Product  3  mass  storage  device.  These 
alphanumeric  files  may  be  modified  or  altered  by  an  authorized  user  using 
the  Knowledge  Acquisition  Interface,  and  may  be  replaced  either  partially  or 
in  their  entirety  in  order  to  update  their  information.  Information  from  these 
files  shall  be  derived  from  a  number  of  sources;  these  sources  and  the 
categories  of  data  to  be  taken  from  them  are  included  in  Appendix  IV. 
Component  inputs  and  outputs  shall  be  as  diagrammed  in  Figure  3-12. 

3.2.3.6.1  Requirements  Allocation 

As  no  functionality  exists  in  this  top  level  component,  no  sepc  ate  lower  level 
components  are  required.  The  entire  data  base  shall  be  equally  accessible 
to  the  Design  Aid  Interface  for  locating  and  displaying  alphanumeric  design 
aid  information. 
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Figure  3-12.  Alphanumeric  Data  Base  tnpuVOutput  Chart 


3. 2. 3. 6.2  Alphanumeric  Data  Base  Component 


a.  Inputs 

Inputs  into  the  Alphanumeric  Data  Base  component  shall  be  the 
pointer  or  pointers  designating  the  alphanumeric  file  or  files  to  be 
accessed  as  a  result  of  three  possible  processes: 

(1)  The  design  search  process  from  the  Design  Aid  Interface 
component. 

(2)  A  request  for  numerical  information  for  statistical  evaluation 
from  the  Analysis  component. 

(3)  A  request  for  file  display  and/or  edit  from  the  Knowledge 
Acquisition  Interface  component. 


InDut 

_  Method 

.  Source 

pointer 

select  file 

pointer  address 

Design  Aid  Interface, 
Analysis, 

Knowledge 

Acquisition  Interface 

b. 

Local  Data 

No  local  data  shall  exist  in  the  Alphanumeric  Data  Base 
component.  The  data  base  information  itself  shall  be  considered 
global,  as  it  is  accessible  by  several  top  level  components.  The 
data  base  structure  and  format  is  discussed  in  detail  in  Appendix 
V. 

c.  Processing 

(1)  Control 

Control  shall  never  be  transferred  to  the  Alphanumeric  Data 
Base  component.  It  shall  accept  a  pointer  and  return  the  file 
designated  by  that  pointer. 

(2)  Algorithms 
Not  Applicable. 


(3)  Spc  :ial  Control  Features 
Not  Applicable. 


(4)  Error  Handling 
Not  Applicable. 

(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 

The  Alphanumeric  Data  Base  shall  not  utilize  other  elements  in 
the  system. 

e.  Limitations 

The  Alphanumeric  Data  Base  shall  be  limited  only  by  the  amount 
of  mass  storage  space  available  to  store  textual  files.  The  system 
shall  warn  the  user  when  disk  reserves  drop  below  10%  of  total 
disk  space. 

f.  Outputs 

The  Alphanumeric  Data  Base  component  shall  output  the 
alphanumeric  file  or  files  specified  as  by  the  input  pointer  to  one  of 
three  possible  components: 

(1 )  The  Design  Aid  Interface  component  for  display. 

(2)  The  Analysis  component  for  statistical  evaluation. 

(3)  The  Knowledge  Acquisition  Interface  component  for  display 
and  editing/updating. 


alphanumeric  file  display  information  direct  output  Design  Aid 

Interface, 

Analysis, 


Knowledge 

Acquisition 

Interface 


3. 2.3.7  Graphics  Data  Base  TLSC 


The  Graphics  Data  Base  component  shall  consist  of  all  prestored  bit¬ 
mapped  graphics  files  containing  data  on  significant  soldier  characteristics. 
These  files  shall  be  created  by  scanning  and  digitizing  already-existing 
graphs,  charts  and  pictures,  and  using  a  bit-mapped  graphics  compression 
algorithm  to  store  them  in  compressed  form  on  the  Product  3  mass  storage 
device.  These  graphics  files  shall  not  be  in  any  way  modified  or  altered  by 
manual  data  entry  operations,  and  must  be  replaced  in  their  entirety  in  order 
to  update  their  information.  Information  from  these  files  shall  be  derived  from 
a  number  of  sources;  these  sources  and  the  categories  of  graphics  to  be 
taken  from  them  are  included  in  Appendix  IV.  Component  inputs  and 
outputs  shall  be  as  diagrammed  in  Figure  3-13. 

3.2.3.7.1  Requirements  Allocation 

As  no  functionality  exists  in  this  top  level  component,  no  separate  lower  level 
components  are  required.  The  entire  data  base  shall  be  equally  accessible 
to  the  Design  Aid  Interface  for  locating  and  displaying  graphical  design  aid 
information. 

3.2.3.7.2  Graphics  Data  Base  Component 
a.  Inputs 

Inputs  into  the  Graphics  Data  Base  component  shall  be  the  pointer 
or  pointers  designating  the  graphics  file  or  files  to  be  accessed 
and  displayed  as  a  result  of  one  of  two  types  of  processes: 

(1 )  The  design  search  process  from  the  Design  Aid  Interface. 


(2) 

The  information  update  process 
Acquisition  Interface. 

from  the  Knowledge 

InDirt 

Method 

Source 

pointer 

select  file 

pointer  address 

Design  Aid  Interface, 

Acquisition 

Knowledge 

Interface 

Outputs 

to  Design  Aid 
Interface 

graphic  file 

M 

■ 

I 


* 


I 

Figure  3-13.  Graphics  Data  Base  Input/Output  Chart 
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b.  Local  Data, 

No  local  data  shall  exist  in  the  Graphics  Data  Base  component. 
The  data  base  information  itself  shall  be  considered  global,  as  it  is 
accessible  by  several  top  level  components.  The  data  base 
structure  and  format  is  discussed  in  detail  in  Appendix  V. 

c.  Processing 

(1)  Control 

Control  shall  never  be  transferred  to  the  Graphics  Data  Base 
component.  It  shall  accept  a  pointer  and  return  the  file 
designated  by  that  pointer. 

(2)  Algorithms 
Not  Applicable. 

(3)  Special  Control  Features 
Not  Applicable. 

(4)  Error  Handling 
Not  Applicable. 

(5)  Data  Conversion 
Not  Applicable. 

(6)  Communication  Interfaces 
Not  Applicable. 

d.  Utilization  of  Other  Elements 
Not  Applicable. 

e.  Limitations 

The  Graphics  Data  Base  shall  be  limited  only  by  the  amount  of 
mass  storage  space  available  to  store  bit-mapped  graphics  files. 
The  system  shall  warn  the  user  when  disk  reserves  drop  below 
10%  of  total  _,sk  space. 
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f.  Outputs 


The  Graphics  Data  Base  component  shall  output  to  the  Design  Aid 
Interface  component  the  bit-mapped  graphics  file  or  files  specified 
as  by  the  input  pointer. 


graphics  file  display  information  direct  output  Design  Aid  Interface 


( 
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4.0  Quality  Assurance  Provisions 

4.1  Introduction  and  Definitions 

A  program  of  tests,  inspections  and  demonstrations,  augmented  by  analysis, 
shall  be  conducted  to  verify  compliance  of  the  Product  3  specification 
requirements  as  stated  in  Section  3.  These  verification  methods  are  defined 
herein. 

a.  Inspection 

Verification  by  examination  of  the  item,  reviewing  descriptive 
documentation,  and  comparing  the  appropriate  characteristics  with  a 
predetermined  standard  to  determine  conformance  to  requirements 
without  the  use  of  special  laboratory  equipment  or  procedures. 

b.  Analysis 

Verification  by  technical  evaluation  using  mathematical 
representations,  charts,  graphs,  circuit  diagrams,  data  reduction, 
and/or  representative  data. 

c.  Demonstration 

Verification  by  operation,  movement,  and/or  adjustment  of  the  item 
under  specific  conditions  to  perform  the  design  function  without 
recording  of  quantitative  data. 

d.  Test 

Verification  through  systematic  exercising  of  the  applicable  item 
under  appropriate  conditions  with  instrumentation  to  measure 
required  parameters  and  the  collection/analysis/evaluation  of 
qu  ntitative  data  to  show  that  measured  parameters  equal  or  exceed 
specified  requirements. 

Table  4-1  specifies  by  paragraph  the  Verification  method(s)  that  shall  be  used 
to  confirm  that  this  requirements  specification  complies  with  the  requirements  as 
stated  in  Section  3.  The  major  test  phases  are: 

a.  18  Month  Demonstration 

b.  24  Month  Acceptance  Test 

4.2  18  Month  Demonstration 

The  1 8  Month  demonstration  will  consist  of  informal  testing  performed  to  obtain 
confidence  and  knowledge  during  the  evolution  of  the  software  and  to  isolate 
and  correct  anomalies.  The  demonstration  shall  be  performed  on  equipment 
that  meets  the  requirements  of  the  Army  Research  Institute  Product  Integration 
Rules,  dated  31  July  1987. 
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4.3  24  Month  Acceptance  Test 

The  24  Month  Acceptance  Test  will  consist  of  formal  qualification  and  " 
acceptance  of  the  prototype  system  and  will  include  verification  of  requirements 
which  could  not  be  validated  in  the  1 8  Month  Demonstration  or  to  demonstrate 
correction  of  anomalies. 

4.4  Verification  Cross  Reference  Matrix  (VCRM) 

Table  4-1  contains  the  VCRM  for  this  specification.  For  each  testable 
requirement  in  Section  3,  the  VCRM  specifies  the  Verification  method  which  will 
be  used  and  the  test  phase  when  the  Verification  will  occur. 

The  columns  in  the  VCRM  describe: 

a.  Requirement  Paragraph  Number 

The  Section  Number  of  the  paragraph  in  Section  3  which  describes 
the  Testable  requirement. 

b.  Paragraph  Title 

The  Section  3  Title  of  the  section  which  contains  the  testable 
requirements. 

c.  Verification  Method 

A  set  of  5  columns  which  indicate  the  method(s)  that  will  be  used  to 
verify  a  testable  requirement  or  to  indicate  that  a  requirement  is  a 
non-testable  requirement.  Verification  Methods  include: 

N  Non  Testable  Requirement 

I  Inspection 

A  Analysis 

D  Demonstration 

T  Test 

d.  Test  Category 

A  set  of  2  columns  which  indicate  the  Test  Category  when  the  testable 
requirement  will  be  verified.  Possible  Test  Categories  are: 

A  18  Month  Demonstration  Test 

B  24  Month  Acceptance  Test 
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Table  4-1  Verification  Cross  Reference  Matrix 


Required 

Paragraph 

Number 

Paragraph  Title 

Design  Requirements 

Top  Level  Design  Requirements 

3.1.1 

Software  Architecture 

3.1. 1.1 

Design  Aid  Interface  Component 

3.1. 1.2 

Search  Process  Record  Component 

3.1. 1.3 

Analysis  Component 

3.1. 1.4 

Knowledge  Acquisition  Interface 
Component 

3.1. 1.5 

Training/Help  Component 

3.1. 1.6 

Alphanumeric  Data  Base 
Component 

3.1. 1.7 

Graphics  Data  Base  Component 

3.1.2 

Functional  Allocation 

3.1.3 

Memory  And  Processing  Time 
Allocation 

3. 1.3.1  • 

Memory  Allocation 

3.1.3.2 

System  Response  Times 

3.1.4 

Functional  Control  And  Data  Flow 

3.1. 4.1 

Functional  Control 

3. 1.4.2 

DataFlow 

3.1.5 

Global  Data 

3.1.6 

Top  Level  Design 

Test 

Category 
A  B 
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Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend 


N  =  No  Testable  Requirement 
I  =  Inspection 
A  *  Analysis 
T  =  Test 

D  =  Demonstration 


Test  Category  Legend 


A  =  18  Months  Demo  Test 
B  =  24  Months  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

3.1. 6.1 

Design  Aid  Interface  TLSC 

3.1. 6.1.1 

Purpose 

3.1. 6.1. 2 

Objective 

3.1.6. 1.3 

General  Description 

3.1. 6.1.4 

Inputs 

3.1. 6.1. 5 

Local  Data 

3.1.6. 1.6 

Sequencing 

3.1. 6.1. 7 

Processing 

3.1. 6.1. 8 

Outputs 

3.1. 6.2 

Search  Proces  Records  TLSC 

3.1.6. 2.1 

Purpose 

3.1. 6.2.2 

Objective 

3  1. 6.2.3 

General  Description 

3.1.6.2.3.1 

Data  Handling 

3.1.6.2.3.2 

Editing  Capability 

3.1. 6.2.4 

Inputs 

3.1.6.2.4.1 

Data  Base  Inputs 

3.1.6.2.4.2 

Design  Aid  Interface  Component 
Inputs 

Test 

Category 
A  B 


Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend 


N  =  No  Testable  Requirement 
I  =  Inspection 
A  =  Analysis 
T  dest 

D  =  Demonstration 


Test  Category  Legend 


A  =  18  Months  Demo  Test 
B  =  24  Months  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

3.1. 6.2.5 

Local  Data 

3.1. 6.2.6 

Sequencing 

3.1. 6.2.7 

Processing 

3.1. 6.2.8 

Outputs 

3.1. 6.3 

Analysis  TLSC 

3.1. 6.3.1 

Purpose 

3.1. 6.3.2 

Objective 

3.1. 6.3.3 

General  Description 

3.1. 6.3.4 

Inputs 

3.1. 6.3.5 

Local  Data 

3.1. 6.3.6 

Sequencing 

3.1. 6.3.7 

Processing 

3.1. 6.3.8. 

Outputs 

3.1. 6.4 

Knowledge  Acquistion  Interface 
TLSC 

3.1. 6.4.1 

Purpose 

3.1. 6.4.2 

Objective 

3.1. 6.4.3 

General  Description 

3.1. 6.4.4 

Inputs 

3.1. 6.4.5 

Local  Data 

3.1. 6. 4.6 

Sequencing 

Test 

Category 
A  B 
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Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend 


N  =  No  Testable  Requirement 
I  =  Inspection 
A  =  Analysis 
T  =  Test 

D  =  Demonstration 


Test  Category  Legend 


A  =  18  Months  Demo  Test 
B  =  24  Months  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

3.1. 6.4.7 

Processing 

3.I.6.5.3.I. 

Outputs 

3.1. 6.5 

Training/Help  TLSC 

3.1. 6.5.1 

Purpose 

3.1. 6.5.2 

Objective 

3.1.6.5.2.1 

Training  Objective 

3.1.6.5.2.2 

Help  Objective 

3.1. 6.5.3 

General  Description 

3.1. 6.5.3. 1 

Training 

3.1.6.5.3.2 

Help 

3.1. 6.5.4 

Inputs 

3.1. 6.5.5 

Local  Data 

3.1. 6.5.6 

Sequencing 

3.1. 6.5.7 

Processing 

3.1. 6.5.8 

Outputs 

3.1. 6.6 

Alphanumeric  Data  Base  TLSC 

3.1. 6.6.1 

Purpose 

3.1. 6.6.2 

Objective 

Test 

Category 
A  B 
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Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend 


N  a  No  Testable  Requirement 
I  &  Inspection 
A  a  Analysis 
T  a  Test 

D  a  Demonstration 


Test  Category  Legend 


A  a  18  Months  Demo  Test 
B  a  24  Months  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

3.1. 6.6.3 

General  Description 

3.1. 6.6.4 

Inputs 

3.1. 6.6.5 

Local  Data 

3.1. 6.6.6 

Sequencing 

3.1. 6.6.7 

Processing 

3.1. 6.6.8 

Outputs 

3. 1.6.7 

Graphics  TLSC 

3.1. 6.7.1 

Purpose 

3.1. 6.7.2 

Objective 

3.1. 6.7.3 

General  Description 

3.1. 6.7.4 

Inputs 

3.1. 6.7.5 

Local  Data 

3.1. 6.7.6 

Sequencing 

3.1. 6.7.7 

Processing 

3.1. 6.7.8 

Outputs 

3.1.7 

Adaptation  Data 

3.1.8 

System  Maintenance 

3.1. 8.1 

Data  Base  Maintenance 

3.1. 8.2 

Account/Access  Maintenance 

Test 

Category 
A  B 


Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend 


N  =  No  Testable  Requirement 
I  =  Inspection 
A  s-  Analysis 
T  «Test 

D  =  Demonstration 


Test  Category  Legend 


A  =  18  Months  Demo  Test 
B  =  24  Months  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

3.2 

Detailed  Design  Requirements 

3.2.1 

Interface  Design 

3.2.1. 1 

Design  Aid  Interfaces 

3.2.1. 1.1 

Design  Aid  Interface/Search 
Process  Record 

3.2. 1.1. 2 

Design  Aid  Interface/Analysis 

3.2.1. 1.3 

Design  Aid  Interface/Knowledge 
Acquisition 

3.2.1. 1.4 

Design  Aid  Interface/Training/Help 

3.2. 1.1. 5 

Design  Aid  Interface/Alphanumeric 
Data  Base 

3.2.1. 1.6 

Design  Aid  Interface/Graphics 

Data  Base 

3.2. 1.2 

Search  Process  Record  Interfaces 

3.2.1. 2.1 

Search  Process  Record/Alpha¬ 
numeric  Data  Base 

3.2.1. 2.2 

Search  Process  Record/Graphics 
Data  Base 

3.2.I.3 

Analysis/Alphanumeric  Data  Base 

Test 

Category 
A  B 
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Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend 


N  =  No  Testable  Requirement 
!  =  Inspection 
A  =  Analysis 
T  =  Test 

D  =  Demonstration 


Test  Category  Legend 


A  =  18  Months  Demo  Test 
B  =  24  Months  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

3.2. 1.4 

Knowledge  Acquisition  Interface 

3.2.1. 4,1 

Knowledge  Acquisition  Interface/ 
Alphanumeric  Data  Base 

3.2.1. 4.2 

Knowledge  Acquisition  Interface/ 
Graphics  Data  Base 

3.2.2 

Global  Data 

3.2.3 

Detailed  Design 

3.2.3.1 

Design  Aid  Interface  TLSC 

3.2.3.1.1 

Design  Aid  Interface  Requirements 
Allocations 

3.2.3. 1.2 

Interface  LLSC 

3.2.3.1.3 

Data  Base  Access  LLSC 

3.2.3.2 

Search  Process  Record  TLSC 

3.2.3.2.1 

Search  Process  Record 
Requirements  Allocation 

3.2.3.2.2 

Create  LLSC 

3.2.3.2.3 

Edit/Print  LLSC 

3.2. 3. 3 

Analysis  TLCS 

3.2.3.3.1 

Requirements  Allocation 

3.2.3. 3.2 

Descriptive  Statistics  LLSC 

3.2.3.3.3 

Transformations  LLSC 

Test 

Category 
A  B 
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Table  4-1  Verification  Cross  Reference  Matrix 


Method  Legend _ 

N  =  No  Testable  Requirement 
i  =  Inspection 
A  =  Analysis 
T  =  Test 

D  =  Demonstration 


Test  Category  Legend 
A  *  18  Months  Demo  Test 
B  =  24  Montns  Accept  Test 


Required 

Paragraph 

Number 

Paragraph  Title 

Verify 
Method 
N  1  A 

T 

D 

Test 

Category 

A  B 

3.2.3.4 

Correlations/Prediction  TLSC 

X 

X 

X 

3.2.3.4.1 

Knowledge  Acquisition  Interface 

X 

X 

Requirements  Allocation  • 

3.2.3.4.2 

Manual  Update  LLSC 

X 

X 

X 

3.2.3.4.3 

Automated  Update  LLSC 

X 

X 

X 

3.2.3.5 

Training/Help  TLSC 

X 

X 

X 

3.2.3.5.1 

Training/Help  Requirements 

X 

X 

Allocation 

3.2.3.5.2 

Training  LLSC 

X 

X 

X 

3.2.3.5.3 

Help  LLSC 

X 

X 

X 

3.2.3.6 

Alphanumeric  Data  Base  TLSC 

X 

X 

3.2.3.6.1 

Requirements  Allocation 

X 

X 

3.2.3.6.2 

Alphanumeric  Data  Base 

X 

X 

Component 

3.2.31 

Graphics  Data  Base 

X 

X 

3.2.3.7.1 

Requirements  Allocation 

X 

X 

ebeebkm 

Graphics  Data  Base  Component 

X 

X 

5.0  PREPARATION  FOR  DELIVERY 

5.1  Genera! 

This  section  details  only  the  preparation  of  the  actual  computer  programs  in 
the  form  of  machine  readable  media. 

5.2  Specific  Requirements 

The  following  MANPRINT  Product  3  software  program  elements  shall  be 
delivered: 

a.  One  set  of  removable  cartridge  and  floppy  disk  media. 

b.  One  set  of  paper  listings  plus  copies  on  magnetic  media. 

5.3  Detailed  Preparation 

5.3.1  Preservation  and  Packaging 

The  delivered  media  should  be  marked  with  the  system  name,  version,  and 
release  data,  plus  the  word  "MASTER."  The  marking  shall  be  on  a  self 
adhesive  label  attached  to  the  media. 

A  directory  of  the  contents  of  the  media,  keyed  to  the  associated 
documentation,  should  be  inserted  into  the  container  (envelope  or  canister). 

5.3.2  Packaging 

The  delivery  media  shall  be  packaged  according  to  good  commerica! 
practice. 


5.3.3  Marking  For  Shipment 

The  delivered  media  shall  be  packaged  according  to  good  commerical 
practice. 
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6.0  NOTES 


6.1  Training  and  Help 

6.1.1  Philosophy 

The  philosophy  underlying  the  approach  to  training  and  help  on  Product  3  is 
derived  from  the  System  Integration  Guidelines  provided  by  the  Army 
Research  Institute: 

Training  will  be  handled  by  a  " self-evident "  interface  and/or  built  in  help. 
Whenever  external  training  (documentation  or  instruction)  is  called  for,  it  must 
be  accompanied  by  an  explanation  as  to  why  this  could  not  be  accomplishea 
by  the  interface  and/or  help. 

6.1.2  Goals 

The  goal,  therefore,  is  to  produce  a  system  that  is  as  self-contained  as 
possible.  While  this  is  a  noteworthy  goal,  in  practice  there  are  circumstances 
in  which  Product  3  should  in  fact  have  off-line  written  documentation.  This 
documentation  need  not  be  provided  directly  to  the  user,  however.  For 
example,  it  is  important  for  the  Army  Research  Institute  (ARI)  to  have  an  explicit 
guide  on  configuring,  installing,  and  maintaining  the  Product  3  software 
system,  presuming  that  they  are  going  to  be  supporting  the  system  in  the  field 
installations.  As  such,  ARI  requires  documentation  on  these  functions  in  order 
to  provide  the  required  support.  The  documentation  provided  by  ARI  to  the 
user  in  the  field  will  draw  upon  the  information  already  available  at  ARI,  but 
may  be  somewhat  less  in  scope. 

6.1.3  Installation/Maintenance  Documentation 

In  a  software  system  this  complex,  for  example,  there  is  no  question  that  when 
it  is  distributed  to  the  field  it  should  be  accompanied  by  installation 
instructions.  The  system  manager  will  require  instruction  on  the  proper 
configuration  of  the  system,  before  it  is  even  used.  This  is  particularly  true  in 
light  of  the  fact  that  it  will  have  the  ability  to  run  off  a  Bernoulli  disk  or  a  fixed 
hard  disk.  These  instructions  will  be  provided  by  ARI,  based  on  the  installation 
guide  provided  to  ARI  with  Product  3.  Furthermore,  these  instructions  may  well 
be  included  in  the  transmittal  letter,  consisting  of  perhaps  two  pages  or  so. 

It  is  also  necessary  to  provide  documentation  for  the  user.  As  much  of  this 
documentation  as  possible  will  be  provided  on-line.  Product  3  must  be 
designed  for  the  user  with  little  or  no  computer  experience,  who  may  not  even 
be  able  to  reach  a  point  in  the  system  at  which  a  Help  function  will  be  useful. 
For  a  new  user  such  as  this,  it  is  important  for  a  training  aid  to  take  them 
through  every  step  of  a  session,  from  turning  of  the  system  at  the  beginning  to 
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turning  it  off  at  the  end.  At  the  same  time,  Product  3  may  have  a  moderately 
experienced  user  who,  however,  does  not  use  the  system  often  enough  to 
remember  the  results  of  all  options  and  selections.  For  this  type  of  individual, 
searching  through  Help  menus  for  brief  memory  joggers  is  not  an  efficient  use 
of  their  time.  For  these  individuals,  any  assistance  required  is  minimal  and 
should  be  presented  as  succinctly  as  possible.  Lastly,  the  system  may  be 
revised,  updated,  or  otherwise  maintained  by  an  individual  at  an  organization 
remote  from  the  user.  Therefore,  the  user  or  other  person  responsible  for 
system  management  locally  must  have  a  working  understanding  of  the  system 
in  order  to  do  system  maintenance  and  limited  troubleshooting.  Such 
maintenance  may  be  as  trivial,  yet  necessary,  as  replacing  data  files  and 
archiving  unneeded  user  files.  However,  in  order  to  accomplish  even  these 
small  tasks,  the  maintainer  must  have  knowledge  of  the  files  that  comprise  the 
system.  Therefore,  a  system  maintainer^  guide  would  round  out  the  external 
documentation  provided  to  ARI  on  Product  3. 

6.1.4  Conclusion 

While  Product  3  will  use  Help  functions  and  on-line  training  to  the  greatest 
extent  possible,  it  is  not  possible  to  satisfy  all  management  and  maintenance 
requirements  solely  through  this  method.  Therefore,  Product  3  on-line 
documentation  will  be  supoorted  will  be  further  supplemented  and  expanded 
upon  by  two  off-line  products  for  the  use  of  ARI  only  as  overall  system 
maintainer:  1 )  an  installation  guide,  and  2)  a  system  maintenance  guide.  It 
is  only  by  the  inclusion  of  these  external  references  that  Product  3  can  fulfill  its 
required  assistance  and  training  functions. 
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6.2  Glossary 

6.2.1  Abbreviations/Acronyms 


ADB  Alphanumeric  Data  Base 

ANA  Analysis  component 

ARI  Army  Research  Institute 

ASI  Added  Skill  indicator 

ARIMA  Box-Jenkins  Autoregressive/Moving  Average  Time  Series 

BIOS  Basic  Input  Output  System 

DAI  Design  Aid  Interface  component 

DIF  Data  Interchange  Format 

DMDC  Defense  Manpower  Data  Center 

DOS  Disk  Operating  System 

EMF  Enlisted  Master  File 

EMS  Extended  Memory  Standard 

FMS  File  Management  System 

GDB  Graphic  Data  Base  component 

ICD  Interface  Control  Drawing 

ICWG  Interface  Control  Working  Group 

KAI  Knowledge  Acquisition  Interface  component 

LAN  Local  Area  Network 

LHASH  Revelation  data  file 

LLSC  Low  Level  Software  Component 

MANPRINT  Manpower  and  Personnel  Integation 

MOS  Military  Occupational  Specialty 

OMF  Officer  Master  File 

RAM  Random  Access  Memory 

ROS  Revelation  data  file 

SPR  Search  Process  Record  component 

TCL  Terminal  Control  Language 

T/H  Training/Help  component 

TLSC  Top  Level  Software  Component 

WAN  Wide  Area  Network 


6.2.2  Terms  Glossary 

Directed  acyclic  graph:  Unidirectional  graph  in  which  no  cycles  occur. 
Bernoulli  disk:  A  class  of  removable  hard  disk. 

Bit-mapped  graphic  images:  A  method  of  storing  images  such  that  each  bit  in 
stored  form  corresponds  directly  to  a  pixel  on  the  screen. 
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Correlation  coefficient:  Statistical  method  used  to  measure  the  strength  of  the 
relationship  between  two  variables. 

Dereferencing:  The  process  of  obtaining  the  value  of  a  pointer. 

Dynamic  memory  allocation:  The  use  of  data  structures  that  can  be  sized  at 
run  time  rather  than  at  compile  time,  enabling  them  to  grow  and  shrink  as  a 
particular  session  requires. 

EGA-based  graphics:  A  graphics  programming  and  display  standard  based 
on  the  functionality  of  the  Enhanced  Graphics  Adaptor  card. 

Extended  Memory  Standard:  A  standardized  method  in  the  Intel  808X/802XX 
microprocessor  family  by  which  memory  greater  than  640K  bytes  is  accessed. 
This  standard  uses  memory  mapping,  a  technique  of  using  the  directly 
accessible  640K  of  memory  as  a  map  into  the  higher  level  memory. 

Linked  list  nodes:  Data  connected  in  memory  through  the  use  of  pointer 
addresses  dereferencing  in  a  linear  manner. 

Full  Screen  Editor.  An  editor  that  permits  the  display  of  text  on  an  entire 
screen,  and  has  facilities  for  the  addition,  modification,  and  deletion  of  text  at 
any  place  on  the  screen. 

Nonparametric  Statistical  Operations:  Any  statistical  evaluation  that  does  not 
assume  a  distribution  for  the  data. 

Local  Data:  Data  created  and  destroyed  in  a  singie  software  component. 

Mass  storage  device:  Method  used  for  the  nonvolatile  (permanent)  storage  of 
information.  Common  forms  are  hard  disks  and  floppy  disks. 

Parametric  Statistical  Operations:  Any  statistical  evaluation  that  assumes  the 
data  follow  the  normal  distribution. 

Project  A  data  base:  A  data  base  developed  by  the  American  Institutes  for 
Research,  under  contract  to  ARI,  that  measures  a  large  number  of  cognitive 
performance  characteristics  on  a  significant  Army  soldier  sample  over  a  period 
of  time. 

Redirection  operator:  A  method  of  directing  program  inputs  and  outputs  using 
other  than  the  standard  input  and  output  devices. 

Revelation:  Revelation  is  the  full-featured  relational  data  base  management 
system  to  be  used  in  Phase  3  development. 


Standard  input  device:  The  default  device  for  input  into  a  computer  system. 
Normally  this  is  the  keyboard. 

Standard  output  device:  The  default  device  for  output  from  a  computer  system. 
Normally  this  is  the  screen  display. 

Taxonomy:  An  ordering  of  soldier  characteristics  and  Army  systems  and 
conditions  used  in  the  Product  3  design  search  process. 

Transformation:  The  modification  of  data  according  to  an  algebraic  function. 

Unmapped  Memory:  Any  main  memory  in  a  computer  system  that  is  accessed 
directly  by  the  processor.  For  an  IBM  PC  compatible,  the  maximum  is  640K 
bytes. 
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APPENDIX  I.  SYSTEM  INTEGRATION  GUIDELINES 

Provided  by  Dr  Jonathan  Kaplan,  Army  Research  Institute,  31  July  1987 

10.1  Application 

All  guidelines  refer  to  the  products  being  developed  as  part  of  the  ARi 
MANPRINT  Methods  Development  Program. 

10.2  Hardware 

All  software  to  be  developed  should  be  able  to  run  on  the  same  hardware. 
The  hardware  of  choice  has  the  following  characteristics: 

a.  Enhanced  graphics  display. 

b.  Enhanced  graphics  board  with  256KB  RAM. 

c.  80286  processor. 

d.  Hard  disk  with  a  minimum  of  20  megabytes  of  storage. 

e.  Up  to  four  megabytes  of  enhanced  memory.  Memory  to  conform  to 
EMS  standard. 

f.  Bernoulli  Box  or  its  functional  equivalent  with  two  removable  20 
megabyte  disks. 

g.  80287  coprocessor  chip  for  intensive  floating  point  computations. 

h.  1200/2400  baud  internal  modem  that  conforms  to  Hayes  standards. 

i.  Floppy  drive(s)  capable  of  read/write  to  360  kilobyte  floppy  diskettes. 

j.  Dot  matrix  printer  with  132  characters  per  line  capability.  Printer  must 
be  capable  of  emulating  IBM  Graphics  and  Epson  FX  and  LQ  series 
printers. 

k.  Mouse  and  mouse  drivers  as  required.  Drivers  for  major  brands  of 
mice  (in  bus  and  com  port  configurations)  should  be  provided. 

l.  An  AT  keyboard. 

10.3  Operating  Systems 

All  software  to  be  developed  should  run  under  the  same  operating  system. 
Until  further  development  results  in  an  available  multitasking  operating 
system,  the  DOS  of  choice  will  be  DOS  3.2.  Any  requirement  for  contacting 


more  than  640  kilobytes  of  memory  will  be  handled  via  the  EMS  standard  for 
enhanced  memory. 

10.4  Product  Interactions 

In  many  cases,  the  output  of  one  of  the  products  will  be  used  as  input  by 
another.  This  means  that  each  product  must  be  able  to  convert  its  output  to 
a  form  (like  ASCII)  that  can  be  understood  by  any  other  product  that  needs  it, 
and  some  mechanism  for  moving  such  files  from  one  machine  to  another 
must  be  provided.  All  products  must  have  alternative  mechanisms  for 
developing  and/or  inputting  these  data.  Potential  product  interactions  are  as 
follows: 

a.  Product  1  receives  no  input  from  any  of  the  other  products. 

b.  Product  2  receives  missions  from  Product  1. 

c.  Micro  Analysis  &  Design  -  DRC's  Product  3  receives  MOS,  and 
maximum  manning  requirements  across  systems  from  Product  2. 

d.  Perceptronics-AIR's  Product  3  receives  missions,  functions,  tasks, 
conditions,  and  criteria  from  Product  1 .  It  receives  MOS  from  Product 
2. 

e.  Product  4  receives  functions,  tasks,  and  criteria  from  Product  1 . 

f.  Micro  Analysis  &  Design  -  DRC's  Product  5  receives  tasks  from 
Product  1  (as  a  fall  back). 

g.  ASA-SAIC's  Product  5  receives  tasks  from  Product  1  (as  a  fall  back). 

h.  Micro  Analysis  &  Design  -  DRC's  Product  6  receives  missions, 
functions,  tasks,  jobs,  number  of  individuals  per  system,  task 
performance  times,  performance  criteria,  and  task  sequences  from 
Product  5.  It  receives  training  times  and  gross  types  of  training  media 
per  function/task  from  Product  4.  It  receives  a  measure  of  central 
tendency  of  each  soldier  characteristic  from  Product  3. 

i.  Analytics'  Product  6  receives  missions,  functions,  tasks,  conditions, 
and  criteria  from  Product  1. Training  times  and  media  per  function/task 
are  received  from  Product  4.  Task  times  and  jobs  (described  as 
groups  of  tasks)  are  received  from  Product  5. 

j.  Perceptronics-Hay's  Product  6  receives  missions,  functions,  tasks, 
conditions  and  criteria  from  Product  1 .  It  receives  jobs  (described  as 
groups  of  tasks)  from  Product  5. 
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10.5  Software 


It  is  acceptable  to  use  off-the-shelf  software  packages  as  components  of  the 
various  products.  Any  such  software  must  be  available  to  the  government 
through  existing  contracts.  It  is  preferable  to  keep  the  number  of  software 
packages  that  the  government  must  purchase  to  a  minimum.  At  present,  it  is 
assumes  that  individual  users  of  the  various  products  wiii  purchase  their 
own  off-the-shelf  software  packages  (rather  than  via  an  ARI  licensing 
agreement).  However,  the  software  produced  for  the  six  products  will, 
without  alteration,  be  able  to  communicate  with  all  required  off-the- 
shelf  software. 

Software  and  data  bases  will  be  available  on  Bernoulli  discs.  However, 
users  will  be  offered  the  option  (by  software)  to  read  from  and  write  to  the 
system’s  hard  disk,  if  they  choose  not  to  purchase  a  Bernoulli.  Master 
Bernoulli  disks  will  be  kept  unused  and  will  be  copied  for  use.  To  allow 
relatively  easy  alterations  of  product  output  thus  permitting  sensitivity 
analysis  and  other  "what  if*  games,  intermediate  files  will  be  saved.  All  such 
intermediate  and  final  output  files  will  be  saved  to  Bernoulli  disk  for  security 
purposes. 

If  social  security  numbers  are  used  in  data  bases  that  are  internal  to  any  of 
these  products,  they  will  be  encrypted.  This  encryption  will  permit  linkage  to 
external  data  sources,  but  will  prevent  product  users  from  identifying  the 
specific  individuals  to  whom  such  data  is  linked. 

Two  commercial  database  management  systems  have  been  selected:  FI- 
Base  V,  and  Pick/Revelation.  No  additional  DBMS  can  be  included  as  a 
product  if  this  inclusion  would  result  in  product  users  having  to  purchase  a 
third  DBMS.  Writing  a  DBMS  to  serve  as  a  component  of  a  product  is 
acceptable. 

in  addition,  such  a  database  must  be  capable  of  editing  inputs  from  other 
products  and  must  be  accessible  via  calls  from  Microsoft  C.  All  users  of 
DBMS  components  in  their  products  must  provide  all  other  teams  with  the 
software  required  to:  open,  access,  and  close  their  DBMS  data/files.  This 
software  must  be  developed  and  provided  no  later  than  six  months  following 
the  start  of  Phase  III.  All  products  will  output  files  in  delimited  fixed  ASCII 
according  to  Data  Interchange  Format  (DIF)  to  permit  data  communications. 

The  development  language  of  choice  is  Microsoft  C. 

A  "cata  Dictionary"  will  be  developed  by  the  various  product  design  teams 
to  facilitate  data  communications  among  the  products.  This  dictionary  will  be 
completed  in  three  months  from  the  start  of  Task  2.  This  dictionary  will  have 
the  following  classes  of  information. 

a.  Field  names. 
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b.  Length  per  field. 

c.  Type  per  field  (alpha,  numeric,  etc.). 

d.  Comment  per  field  (description  of  contents). 

e.  "Parent-child"  relationship  per  field  (Where  does  it  come  from  and 
where  does  it  go  in  a  hierarchy). 

f.  Range  per  field. 

g.  Name  of  each  record. 

h.  Estimated  numbers  of  records. 

10.6  User  Interfaces 

It  is  critical  that  the  user  interface(s)  of  all  the  MANPRINT  products  be 
designed  in  a  manner  that  makes  their  operation  as  simple  and  self-evident 
as  possible.  The  object  of  these  products  is  to  aid  personnel  who  have 
limited  or  no  computer  experience.  Six  of  the  ten  design  teams  have 
specified  their  intention  to  develop  a  common  interface  based  upon  the 
interface  of  Borland's  Turbo  C.  The  following  requirements  apply  to  any 
interface  that  is  to  be  used  by  any  product.  They  are  mandatory. 

a.  The  user  will  not  have  to  memorize  command  language. 

b.  Training  will  be  handled  by  a  "self-evident"  interface  and/or  built  in 
help.  Whenever  external  training  (documentation  or  instruction)  is 
called  for,  it  must  be  accompanied  by  an  explanation  as  to  why  this 
could  not  be  accomplished  by  the  interface  and/or  help. 

c.  If  a  mouse  is  used,  equivalent  keyboard  entries  must  be  available  to 
the  user. 

d.  Vocabulary  meaning  must  be  consistent  across  all  products.  That  is, 
whenever  a  term  (condition,  criterion,  characteristic,  etc.)  is  used,  it 
must  always  mean  the  same  thing  in  each  product.  An  on-line 
glossary  providing  definitions  of  all  key  terms  will  be  available  as  part 
of  each  product. 

e.  If  an  interface  requires  use  of  hierarchically  nested  menus  that  are 
more  than  two  menus  deep,  a  mechanism  must  be  provided  the  user 
to  show  him  where  in  the  menu  structure  he  is  at  any  time.  This 
mechanism  must  be  common  across  all  products  (if  used). 
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f.  If  a  given  product  requires  more  total  effort  of  its  user  than  can  be 
done  in  a  continuous  three  hour  period,  then  the  interface  must 
provide  the  following  two  features: 

(1)  A  mechanism  for  returning  to  the  last  procedure  after  the 
system  has  been  turned  off. 

(2)  A  mechanism  for  seeing  which  procedures  have  been 
done  and  which  have  not  been  done  at  any  given  time. 

g.  To  the  extent  possible,  natural  language  wiil  be  used.  That  is,  neither 
computer  nor  psychology  jargon  will  be  used  to  communicate  unless 
a  given  word  is  now  in  the  common  domain. 

h.  If  color  coding  is  used,  it  must  have  the  same  meaning  across  all 
products. 

i.  If  function  keys  are  used,  they  must  have  the  same  effects  across  all 
products  if  at  all  possible.  If  such  commonality  is  impossible,  another 
sort  of  communication  mechanism  should  be  considered. 

j.  Housekeeping  procedures  (starting,  closing,  saving,  restoring,  etc.) 
should  be  identical  across  all  products  from  the  point  of  view  of  the 
user. 

k  Users  should  be  given  the  option  of  changing  the  foreground  vs 
background  colors.  That  is,  dark  letters-light  background  or  the 
reverse. 

l.  Each  product  will  be  used  more  than  once.  Therefore,  the  names  of 
the  files  that  are  generated  must  be  able  to  be  viewed  and  selected. 
The  procedures  for  doing  this  should  be  as  similar  as  possible  across 
products  (from  the  point  of  view  of  the  user). 

m.  Each  product  must  include  an  enhanced  graphics  driver,  mouse 
drivers,  and  printer  drivers  that  will  operate  at  minimum  IBM,  and 
Epson  FX  and  LQ  series  printers. 

n.  From  the  point  of  view  of  the  user,  all  editing  conventions  should  be 
the  same  across  all  products.  Editing  includes:  entering,  deleting, 
altering,  moving,  and  copying  text.  Editing  conventions  include  the 
selection  of  keys  for  moving  the  cursor,  deleting,  entering,  copying, 
etc.  Editing  conventions  should  be  as  simple  and  self-evident  as 
possible. 
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APPENDIX  II.  LANGUAGE  SPECIFICATION  • 

20.1  Application 

This  Appendix  provides  details  on  the  specifications  for  the  operating 
system,  development  languages,  and  applications  software  languages  to  be 
used  in  the  development  of  Product  3.  The  major  components  of  each 
products  software  system  shall  be: 

1.  Operating  System; 

DOS  3.xx 
CONFIG.  SYS 
ANSI.SYS 
VDISK.SYS 
FILENAME.BAT 

2.  System  Utilities; 

ASM.COM* 

3.  System  Applications;  and, 

MSOFT_C.COM* 

4.  Relational  Data  base. 

REVELATION: 

TCL 

RBASIC 

(‘Generic  FileHandles.) 

20.2  General  Description 

Product  3  shall  have  stand  alone  software  systems  consisting  of  these  four 
major  software  component  blocks.  Each  of  these  system  blocks  represents 
an  area  that  involves  some  level  of  software  language  development. 


20.2.1  Operating  System 

Product  3  shall  be  fully  compatible  with  and  run  under  either  MS-DOS  3.xx 
or  MS-DOS  3.xx.  Actual  development  shall  be  conducted  using  MS-DOS 
3.3  since  earlier  versions  are  no  longer  commercially  available.  Beta  tests 
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will  be  conducted  using  MS-DOS  3.2  to  insure  reverse  compatibility1.  The 
products  will  make  full  use  of  DOS  capabilities  to  perform  such  functions  as 
batch  processing,  execution  of  external  applications  software,  maintenance 
of  the  native  file  system,  I/O  control  and  all  of  the  other  normal  DOS 
functions.  The  software  shall  use  the  extended  DOS  environment  to 
maintain  the  path,  and  pass  link,  control  strings  and  data  between  the  data 
base  and  external  applications.  The  software  shall  configure  DOS  to  take 
full  advantage  of  the  extended  control  offered  by  the  ANSI. SYS.  The  user 
may  optionally  run  the  products  in  a  system  having  memory  that  is  expanded 
above  the  DOS  640  KBYTE  maximum  by  configuring  a  disk  cache  or  a 
simple  RAMDISK,  using  VDISK.SYS.2 

20.2.2.  System  Utilities 

A  variety  of  system  utilities  shall  be  developed  in  assembly  language  and 
assembled  using  Microsoft's  Macro  Assembler,  4.0.  Assembly  language 
shall  be  chosen  when  either  speed,  compact  code,  or  direct,  low  overhead, 
calls  to  the  BIOs  interrupts  are  a  primary  requirement.2 

20.2.3.  System  Applications 

System  applications  programs  shall  be  developed  using  C  compatible  with 
Microsoft's  C  Compiler  and  run-time  library.4  All  information  outputs  and 
Revelation  data  base  files  shall  be  accessible  through  standard  Microsoft  C 
run-time  library  I/O  and  file  handling  routines. 


1  IBMAITechnical  Reference  Manual-  IBM  Corp..  1985. 

IBM  DOS  3.1  Technical  Reference  Manual.  IBM  Corp.,  1985. 
lEM-PQS-32-Manuaj-  IBM  Corp.,  1986. 

1SMJ2Q s .  3-2  J eshmeaLBstg ran ca  Manual-  ibm  corp.,  1986. 

IBM  DOS  3.30  Manual.  IBM  Corp.,  April  1987. 

IBM  DOS  3.30  Technical  Reference  Manual.  IBM  Corp.,  April  1987. 

2  Lotus  Intel  Microsoft  Expanded  Memory  Specification.  Version 
3.20.  U.S.A.:  Lotus  Development  Corporation,  Intel  Corporation, 
Microsoft  Corporation,  1985. 

3  Miciosoft  Macro  Assembler  for  the  MS-DOS  Operating  System. 
Version  4.00.  Microsoft  Corp.,  1985. 

Proceedings.  Memory  Resident  Utilities  Conference,  May  1986. 
Microsystems  Components  Handbook.  U.SA:  Intel  Corporation, 
1985. 

4  Microsoft  C  Run-Time  Library  Reference.  Microsoft  Corp.,  1985. 
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20.2.4  Relational  Data  Base 


Product  3  shall  be  developed  using  the  REVELATION  relational  data  base 
software.5  The  data  base  languages  used  in  the  development  of  the 
product  3  relational  data  bases  shall  be  Revelation  Terminal  Control 
Language  (TCL)  and  RBASIC.  Revelation  provides  an  applications 
generator  that  parses  TCL  query  sentences  and  compiles  RBASIC 
programs.  RBASIC  compiled  programs  are  structured  according  to  the 
precedents  of  the  parser,  and  are  self  documented. 

The  Revelation  applications  generator  shall  be  used  to  generate  the  base 
structures  for  all  data  base  programs.  Each  of  the  programs  shall  then  be 
minimally  customized  to  fit  the  MANPRINT  products  interface  requirements, 
i  This  use  of  the  applications  generator  shall  provide  uniform  quality 

assurance  across  programs  and  produce  standard  documentation  of  all  of 
j  the  applications  programs  generated  across  the  two  products.  (The 

!  importance  of  this  feature  of  the  Product  3  programs  can  not  be 

overstressed.)  All  of  the  applications  programs  shall  be  structured, 

I  programmed,  and  documented  using  identical  formats.  All  of  the  programs 

shall  share  the  same  set  of  algorithms,  appearing  in  the  same  locations 
within  the  source  code.  This  will  yield  products  that  have  maximal  future 
growth  and  development  capability. 


5  Revelation  Technical  Reference  and  User's  Guide.  Cosmos,  Inc, 
1985. 
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APPENDIX  III.  USER-SYSTEM  INTERFACE 
DESIGN  REQUIREMENTS 


30.1  Background 

MANPRINT  User-system  interface  (USI)  software  requirements  have  been 
extracted  from  MIL-STD-1472C,  Human  Engineering  Design  Criteria  for 
Military  Systems,  Equipment  and  Facilities,  Section  5.15,  ESD-TR-86-278, 
Guidelines  for  Designing  User  Interface  Software,  and  AFAMRL-TR-85-013, 
Person  Computer  Dialogue:  A  Human  Engineering  Data  Base  Supplement. 
Figures  30-1  through  30-5  provide  illustrative  operations  and  maintenance 
menu  screens.  To  the  extent  possible  and  as  available,  Product  3  detailed 
design  of  USI  procedures  shall  strive  to  incorporate  any  future  USI 
standards  that  will  be  established  for  all  MANPRINT  products,  including  but 
not  limited  to  viewing  and  selecting  files,  function  keys,  housekeeping 
procedures  (e.g.,  starting,  closing,  saving, storing,  etc.),  and  vocabulary 
meanings. 

30.2  Requirements. 

Product  3  USI  software  shall  be  developed  in  accordance  with  the 
requirements  of  the  following  sections. 

30.2.1.  Minimization  of  User  Training  Requirements 

The  USI  design  goal  shall  be  to  minimize  the  amount  of  time  and  effort 
required  by  a  user  to  become  proficient  in  use  of  Product  3  procedures.  As  a 
minimum,  USI  features  shall  comply  with  the  following  general 
requirements: 

a.  Interactive  procedures  including  the  use  of  function  keys  shall  be 
consistent  within  and  between  all  types  of  data  entry,  sequence 
control,  display,  and  printing  operations. 

b.  Operator  effort  shall  be  minimized  in  control  and  entry  actions. 

c.  Wording  of  messages  and  displays  shall  be  in  plain  English 
(natural  language)  or  match  MANPRINT  user  job-oriented 
vocabulary.  The  user  shall  not  be  required  to  memorize  command 
language. 

d.  Abbreviations  and  acronyms  shall  be  used  only  when  they  are 
significantly  shorter  than  the  full  text  and  can  be  easily  understood 
by  a  Product  3  user. 

e.  USI  control  requirements  shall  not  require  the  user  to  memorize  a 
command  language. 
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Program:  MANPRINT  Date:  9/12/87 

Operation _  Time:  13:00:00 
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Figure  30-2.  Illustrative  Product  3  Second  Level  Menu 


Program:  MANPRINT  Dale:  9/12/87 

Operation _  Time:  13:00:00 


I 
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Figure  30-3.  Illustrative  Product  3  Third  Level  Menu 


Design  Access  Tools  Management  Exit 
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Figure  30*4.  Illustrative  Product  3  Maintenance  Lower  Level  Menu  *  Page  1  of  2 


Design  Access  Tools  Management  Exit 


Figure  30-4.  Illustrative  Product  3  Maintenance  Lower  Level  Menu  *  Page  2  of  2 


f  Users  shall  not  be  required  to  translate,  compute,  convert, 
interpolate  or  otherwise  mentally  manipulate  data  when 
interpreting  displays  or  messages,  or  performing  data  input  or 
control  functions. 

g.  The  operator  shall  receive  positive  acknowledgement  of  all 
command  inputs,  that  are  legal,  valid,  and  have  been  accepted  for 
processing.  This  acknowledgement  shall  be  the  immediate 
display  of  requested  information  or  an  acknowledgement 
message  for  those  inputs  that  cause  processing  not  visible  to  the 
user. 

h.  Product  3  software  shall  check  for  obvious  errors.  Reporting  of 
errors  shall  be  in  accordance  with  the  requirements  in  paragraphs 
30.2.8  d  &  e.  of  this  Appendix. 

i.  The  user  shall  have  the  option  of  changing  the  foreground  vs.  the 
background  colors  of  the  display  screens. 

30.2.2  Data  Entry 

Product  3  data  entry  functions  shall  comply  with  the  following  requirements: 

a.  The  user  shall  not  be  required  to  enter  data  which  is  already 
available  within  Product  3  software  or  data  files. 

b.  Normal  default  values  shall  be  provided  wherever  applicable  to 
speed  data  entry.  The  user  shall  have  an  easy  means  to  accept  or 
change  default  values. 

c.  The  user  shall  not  be  required  to  enter  leading  or  trailing  blanks  or 
zeros.  If  data  items  are  always  preceded  or  followed  by  special 
characters,  the  characters  shall  be  supplied  by  the  Product  3 
software. 

d.  For  complex  data  inputs,  prompts  shall  be  provided  to  guide  the 
user  and  minimize  data  input  errors. 

e.  All  user  inputs  shall  be  checked  for  validity  and  completeness. 
When  feasible,  erroneous  inputs  shall  be  identified  and 
recommended  alternatives  shall  be  provided  to  the  user. 

f.  Data  entry  screens  shall  be  organized  to  minimize  user  search 
and  retrieval  efforts. 

h.  The  normal  position  for  the  cursor  during  data  entry  shall  be  at  the 
first  location  where  data  could  be  entered.  Areas  of  the  screen  not 
needed  for  data  entry  shall  be  inaccessible  to  the  user. 
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i.  The  user  shall  be  allowed  to  enter  data  by  character  replacement, 
such  as  underscores  or  default  values. 

j.  For  complex  data  entry  screens,  the  user  shall  be  able  to  work  on 
the  whole  data  entry  screen  before  transmitting  it  to  the  Product  3 
software. 

k.  Editing  conventions  (e.g.,  selection  of  keys  for  moving  the  cursor, 
deleting,  entering,  copying,  etc.)  shall  be  as  simple  and  self- 
evident  as  possible. 

30.2.3  Data  Display 

Product  3  data  compilation  and  displays  of  compilations  shall  comply  with 

the  following  requirements: 

a.  Product  3  displays  shall  have  a  title  that  clearly  and  specifically 
desi  ibes  their  contents. 

b.  The  home  position  of  the  cursor  shall  be  in  a  consistent  position 
across  similar  types  of  displays. 

c.  Similar  screens  shall  be  displayed  in  a  consistent  format. 

d.  The  user  shall  automatically  be  presented  with  the  top  level  menu 
immediately  upon  logging  into  the  system. 

30.2.4  Text  Display 

a.  Text  screens  shall  use  mixed,  upper  and  lower  case  characters 
with  appropriate  punctuation. 

b.  Text  shall  be  left  justified  but  with  a  ragged  right  margin. 

30.2.5  Display  of  Data  Tables 

a.  Columns  and  rows  of  tables  shall  have  meaningful  titles. 

b.  Items  in  tables  shall  be  in  a  recognizable  order  that  will  facilitate 
user  comparisons  and  scanning. 

c.  Items  in  multiple  column  tables  shall  be  in  vertical  columns  that 
are  read  from  left  to  right. 

d.  Alphabetic  data  in  tables  shall  be  left  justified  while  numeric  data 
shall  be  right  justified  or  aligned  by  a  decimal  point  or  other 
delimiter. 


e.  A  blank  line  shall  be  inserted  after  about  every  fifth  item  in  a  long 
table. 

f.  Long  strings  of  alphanumeric  data  shall  be  broken  up  into  smaller 
groups  of  three  to  four  characters. 

30.2.6  Graphic  Display 

a.  Actual  data  values  shall  be  used  to  supplement  their  graphic 
representation  when  precise  reading  of  a  graphic  display  is 
required. 

b.  Scales  shall  be  constructed  with  tick  marks  at  a  standard  interval 
of  1,2,5,10  or  multiples  of  10. 

c.  The  following  guidelines  shall  be  used  for  the  selection  of 
appropriate  graphic  display  formats: 

(1)  Smooth  curves  or  line  graphics  shall  be  used  for  displaying 
relations  between  two  continuous  variables. 

(2)  Bar  graphs  shall  be  used  for  comparing  a  single  measure 
across  a  set  of  several  entities  or  for  a  variable  sampled  at 
discrete  intervals.  * 

(3)  Pictorial  displays  shall  be  used  when  it  is  necessary  to  show 
accurately  detailed  representations  of  real  or  imaginary 
objects. 

30.2.7.  Highlighting 

a.  Highlighting  methods  shall  be  selected  that  are  appropriate  for  the 
level  of  importance  of  the  information  being  displayed. 

b.  Blinking  displays  shall  be  used  only  to  highlight  critical  information 
that  requires  an  immediate  response  from  the  user. 

30.2.8.  Messages 

Product  3  messages  shall  include  prompts,  help  instructions,  and  error 
messages  which  shall  comply  with  the  following  requirements: 

a.  Messages  shall  be  displayed  in  a  standard  location. 

b.  Messages  shall  use  plain  English  or  MANPRINT  job-oriented 
language. 
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c.  Help  messages  shall  describe  procedures  in  logical  order.  Where 
appropriate, examples  of  required  responses  shall  be  provided. 

d.  Error  messages  shall  be  as  detailed  as  possible  to  explain  the 
cause  of  an  error  without  using  error  codes.  Whenever  possible, 
the  message  shall  indicate  corrective  action  to  be  taken. 

e.  Error  messages  shall  be  neutral  and  not  assign  blame  to  the  user 
or  the  Product  3  software. 

30.2.9  Sequence  Control 

Product  3  sequence  control  procedures  shall  comply  with  the  following 
requirements: 

a.  Whenever  possible,  Product  3  software  shall  use  menus  and 
function  keys  to  control  the  sequence  of  actions.  Each  menu 
screen  shall  have  a  title  at  the  top  which  describes  its  purpose  . 

b.  To  the  greatest  extent  possible,  menu  levels  shall  be  limited  to 
two.  If  an  interface  requires  nested  menus  more  than  two  menus 
deep,  the  user  shall  be  provided  with  a  display  to  show  the 
location  of  the  level  within  the  menu  structure  at  all  times. 

c.  Menu  options  shall  be  ordered  by  either  their  expected  frequency 
of  use  or  their  logical  sequence  of  operation. 

d.  When  the  menu  options  consist  of  phrases  or  sentences,  they 
shall  be  displayed  in  mixed,  upper  and  lower  case  letters. 

e.  On  menu  screens,  the  cursor  shall  be  placed  automatically  in  the 
same  location  on  the  screen,  normally  in  the  area  where 
commands  are  entered. 

f.  Whenever  possible,  "Pop-up"  menus  shall  use  simple  active  verbs 
as  menu  options. 

g.  The  menu  levels  shall  be  designed  to  show  the  user  where  he  is 
in  the  structure  at  any  time.  The  user  shall  be  able  to  easily  return 
to  the  top  level  menu  from  any  menu. 

h.  Function  keys,  if  applicable,  shall  be  used  to  speed  up  the 
execution  of  frequently  used  or  critical  operations. 

i.  The  sequence  control  procedures  shall  provide: 

(1)  A  mechanism  for  returning  to  the  last  procedure  after  the 
system  has  been  turned  off,  and 
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(2)  A  mechanism  for  returning  to  the  last,  procedure  after  the 
system  has  been  turned  off.. 

30.2.10.  Data  Security 

Product  3  USI  data  security  procedures  shall  comply  with  the  following 
requirements: 

a.  When  an  operator  action  interrupts  a  current  transaction 
sequence,  an  automatic  means  shall  be  provided  to  prevent  data 
loss. 

b.  Automatic  measures  shall  be  provided  to  minimize  data  loss  from 
computer  failure. 

c.  Product  3  USI  procedures  shall  ensure  that  software  changes 
data  only  as  a  result  of  explicit  actions  by  the  user. 

d.  A  confirm  capability  shall  be  provided  for  user  confirmation  of  a 
potentially  destructive  action. 
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APPENDIX  IV.  DATA  BASE  STRUCTURE  AND  USER 

PRESENTATION 


40.1  Background 

This  appendix  will  describe  the  data  base  structure,  user  presentation, 
process  control,  and  data  dictionary.  The  soldier  characteristics  data  bases 
pro  mejor  components  of  the  MANPRINT  Product  3  software  system.  The 
complete  data  base  shall  consist  of  textual  and  graphical  information  about 
human  characteristics  which  are  relevant  and  significant  for  the 
establishment  of  design  constraints  for  the  acquisition  of  Army  systems.  As  a 
minimum,  these  characteristics  shall  be  compiled  from  the  sources  and 
organized  into  the  taxonomy  depicted  in  Table  40-1.  Complete  evaluation 
and  determination  of  the  data  base  variables  shall  be  completed  in 
MANPRINT  Phase  III.  The  data  base  will  interact  with  the  other  components 
of  Product  3  to  assist  the  user  in  producing  detailed  and  precise 
requirements,  and  therefore,  increase  the  likelihood  that  the  requirements 
will  be  completely  implemented  in  systems  the  Army  acquires. 

40.2  Design  Aid  Interfaces 

40.2.1  Design  Aid  Interface  Operation 

The  design  aid  interface  operation  is  a  data  reduction  process  in  which 
Product  3  shall  eliminate  those  soldier  characteristics  which  are  not  relevant 
to  the  user's  specific  needs.  The  design  aid  interface  shall  consist  of 
queries,  in  the  form  of  menus,  from  which  the  user  will  select  those 
descriptors  which  relate  to  the  system  in  question.  An  example  of  a 
relational  menu  query  appears  in  Figure  40-1. 

40.2.2  System  Parameters 

a.  The  reduction  of  soldier  characteristics  from  the  total  data  base 
shall  proceed  based  on  a  predetermined  mapping  of  the 
characteristics  to  Army  system  parameters.  The  Army  system 
parameters  selected  shall  be  based,  in  part,  on  the  MANPRINT 
Product  1  taxonomy  of  Army  systems.  The  criteria  for  the  selection 
of  descriptors  from  the  Product  1  taxonomy  shall  be  the  ability  of 
the  descriptor  to  discriminate  among  soldier  characteristics  (e.g.,  if 
the  descriptor  tank"  were  selected  from  the  list  in  Figure  40-1, 
human  characteristics  related  to  threshold  altitudes  and 
physiologic  limitations  related  to  helicopters  would  be  eliminated 
from  the  subset  of  characteristics  Product  3  would  produce). 

b.  Additional  system  parameter  descriptors  shall  be  derived  in  Phase 
III,  based  on  the  criteria  of  their  ability  to  discriminate  among 
variables  and  the  anticipated  availability  of  the  information  at  an 
early  system  acquisition  phase.  Detailed  task  data  is  not 
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Cognitive 

verbal  ability 
numeric  ability 
spatial  ability 
reasoning 
mental  processing 
perceptual  speed/accuracy 
Short-term  memory 
mechanical  comprehension 


Psyehomotor 

eye-limb  coordination 
movement  judgement 
arm-hand  steadiness 
equilibrium 
finger  dexterity 
manual  dexterity 
control  precision 


MOS  General  Characteristics 

skill  level 

pay  grade/date 

enlistment  date 

training 

sex 

age 

citizenship 
attntion  rate 


MOS  aptitude/abilltles 

years  of  education 
education  certification 
mental  category 
AFQT  %  Score 


Environmental 


volume 
temperature 
vibration,  impact 


acceleranon 
'  illumination . 


Sensory  Capabilities 


hearing . 

vision . 

eontroi/display 
user'  system  interface ' 


Table  40-1.  Matrix  of  Soldier  Characteristics  Taxonomy  ar.d  Data  Sources 


'  AF  -  Accession  File,  EMF  -  Enlisted  Master  File,  OMF  -  Officer  Master 
File,  DMDC  -  Defense  Manpower  Data  Center 
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DATA  SOURCES 


Human  Strength 

fifting/earrying 
push/pull  forces 
hand  dynameter 

common  control  operational  force 

strength  in  relation  to  control 

static  strength 

explosive  strength 

dynamic  strength 

stamina 


Anthropometric 


shirt  sleeved 


artic  gear 
‘ftSC'gear 


Ground  Workspace  Design 


Design  tor  Maintainability 


Design  tor  Remote  Handling 


Biomedical 

noise  levels 


toxicological 

radiological 


Life  Support 


sleep  ioss/tatigue 


respiratory  environmental 
systems 


Design  ot  Equipment 'tor  Remote 
Handling 

Small  Systems  A  Equipment 
Operational  A  Maintenance  Ground/ 
Shipboard  Vehicles 


Table  40-1.  Matrix  of  Soldier  Characteristics  Taxonomy  and  Data  Sources 


’  AF  •  Accession  File.  EMF  •  Enlisted  Master  File.  OMF  -  Officer  Master 
File,  DM  DC  -  Defense  Manpower  Data  Center 
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TANK 

ARMORED  PERSONNEL  CARRIER 
UNARMORED  VEHICLE 
HELICOPTER 
FIXED  WING  AIRCRAFT 
SMALL  ARMS 


Figure  40-1.  Example  Relational  Menu  Query  Text 


anticipated  to  be  known  and  shall  therefore  not  be  included. 
However,  certain  system  parameters  related  to  personnel  may  be 
known  early  (e.g.,  the  decision  for  crew  size:  2-man  tank,  6-man 
tank,  etc.,  would  generally  accompany  early  system 
conceptualization.  Therefore,  a  query  of  crew  size  would  be 
appropriate  for  inclusion  because  it  influences  minimum  volume 
requirements  and  because  the  information  should  be  available). 

40.2.3  Description  of  Process 

a.  When  the  user  begins  a  Product  3  design  aid  interface  process, 
the  entire  data  base  shall  be  available.  As  more  and  more 
descriptors  are  selected  which  specify  the  system  of  interest  to  the 
user,  the  system-specific  data  base  shall  become  a  smaller  and 
smaller  subset  of  the  original  data  base.  All  dialogue  screens 
shall  have  a  user  option  to  continue  the  search  without 
designating  a  specific  descriptor.  Multiple  descriptors  may  also  be 
selected  from  a  single  list,  if  appropriate. 

b.  Once  initiated,  the  design  aid  dialogue  shall  proceed  according  to 
the  responses  of  the  user  until  its  conclusion,  unless  the  user 
chooses,  at  any  point,  to  terminate  the  dialogue  and  to  either: 

(1 )  Proceed  to  the  point  where  the  dialogue  would  end; 

(2)  Return  to  the  main  menu;  or 

(3)  Save  the  partially  completed  dialogue  until  a  latter  time. 

c.  If  the  user  selects,  at  any  point  in  the  dialogue,  to  terminate  the 
dialogue  but  to  proceed  to  its  normal  conclusion  point,  the  Product 
3  system  shall  respond  as  if  the  user  had  proceeded  through  the 
entire  dialogue,  with  defaults  for  all  queries  past  the  termination 
request. 

d.  At  the  design  aid  dialogue  conclusion  point,  a  subset  of  system- 
specific  soldier  characteristics  shall  have  been  defined  according 
to  the  user's  inputs  and  the  predetermined  relationships  between 
system  parameters  and  soldier  characteristics.  This  subset  shall 
be  made  available  through  the  menus.  The  top  level  menu  will 
contain  the  major  categories  such  as  cognitive,  psychomotor,  etc. 
The  user  shall  select  a  category  and  one  or  more  lower  level 
menus  shall  be  presented  according  to  the  appropriateness  of 
further  subdividing  the  topic  area. 

e.  The  users  shall  always  be  able  to  know  where  they  are  within  the 
data  base  menu  structure  and  shall  easily  be  able  to  move 
between  menu  levels  and  menu  categories. 


40.3  Data  Base  Manipulations 

Textual  and/or  graphic  displays  shall  be  presented  to  a  user  after  selection 
from  the  main  menu  (e.g. ."Environmental"  and  from  the  lower  level  list  of 
"Vibration  Tolerances").  For  multiple  displays  with  textual  and/or  graphical 
data,  each  display  shall  remain  on  the  screen  until  the  user  selects  an 
option  to  advance  one  display,  go  back  one  display,  return  to  higher  level 
memory,  or  exit.  The  alphanumeric  data  may  be  edited,  stored,  and  printed 
on  hard  copy.  This  shall  allow  the  user  to  accumulate  a  set  of  soldier 
characteristics,  edit  them  as  required  to  be  appropriate  for  a  specific  use. 
and  produce  a  hard  copy  which  will  be  easily  transferable  to  a  design 
specification  or  RFP.  Figure  40-2  presents  an  illustrative  display  example  of 
maximum  levels  of  human  vibration  tolerances.  This  statement  could  be 
edited  by  the  user  to  be  appropriate  for  a  design  specification  as  follows: 

3.3.6. 1  Vibration.  The  X-Tank  shall  be  designed  to  impose  a  maximum  of  6- 
watts  of  absorbed  power  to  the  crew  seat. 

40.4  Data  Base  Contents 

The  contents  of  the  data  base  shall  consist  of  significant  soldier 
characteristics  which  are  presented  in  a  format  which  shall  be  useful  for 
MANPRINT  specialists  responsible  for  developing  Army  system  design 
constraints  which  relate  to  human  performance.  Table  40-2  shows  the  top 
level  and  second  level  categories  of  soldier  characteristics  presented  in 
Table  40-1,  broken  out  a  third  level  where  appropriate.  Each  broad  topic 
area  is  discussed  below. 

40.4.1  Cognitive/Psychomotor 

a.  All  of  the  cognitive  dimensions  and  two  of  the  psychomotor 
dimensions  (eye-limb  coordination  and  movement  judgment)  shall 
originate  from  measures  within  the  Project  A  data  base.  Individual 
Project  A  measures  shall  be  organized  into  a  smaller  number  of 
relatively  distinct  factors,  following  Wing,  et.  al.  (1985)*-. 
Personality  and  temperament  measures  are  omitted  as  these  are 
less  obviously  related  to  the  performance  of  specific  types  of  tasks. 
The  remaining  measures  are  organized  into  10  dimensions.  The 
10  dimensions,  and  specific  Project  A  tests  that  measure 
individual  differences  along  these  dimensions,  are  presented  in 
Tables  40-3  and  40-4.  The  Project  A  data  will  provide 


1  Wing,  H.  Peterson,  N.G,  &  Hoffman,  R.G.  (1984,  August).  Expert  judgements  of 
predictor-criterion  validity  relationships.  Paper  presented  at  the  Annual  Convention  of 
the  American  Psychological  Association,  Toronto,  Canada.  (In  ARI  Technical  Report  660. 
July  1985;  appendices  in  ARI  Research  Note  85-14,  October  1984.) 
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Vibration  does  not  typically  affect  human  reaction  time.  When  reaction 
time  is  affected  during  or  following  vibration  exposure,  only  several  one- 
hundredth  of  a  second  are  added  to  the  static  base  reaction  time,  normally 
0.02  to  0.05  seconds.  Increases  in  vibration  intensity  or  duration  do  not 
produce  corresponding  changes  in  reaction  time. 

Visual  Impairment 

Visual  impairment  is  extremely  sensitive  to  the  specific  vibration/task 
situation.  In  general,  the  range  of  10  to  24  Hz  is  most  detrimental  to  visual 
performance.  In  a  supine  position,  a  helmet  can  reduce  visual  error  when 
motion  is  in  the  x-axis.  However,  significant  error  reduction  in  the  z-axis 
results  when  the  head  can  move  freely.  There  is  some  indication  that 
higher  frequencies  (1 1  and  15  Hz)  in  the  z-axis  may  result  in  larger  error 
when  a  helmet  is  worn.  In  general,  tasks  that  measure  central  neural 
processes  such  as  reaction  time,  monitoring,  and  pattern  recognition, 
appear  to  be  highly  resistant  to  degradation  during  vibration. 

Visual  blum'ng  occurs  at  0.40  Root  Mean  Square  (RMSq)  1-1000  Hz,  for  a 
40  minute  exposure. 

Maximum  Levels 

Vehicles  should  be  designed  so  as  not  to  impose  vibration  on  its 
occupants  in  excess  of  6-watts  of  absorbed  power.  Beyond  this  level  there 
is  a  risk  of  human  injury  and  cargo/vehicle  damage. 


Figure  40-2.  Alphanumeric  Data  Base  Display  Screen  Text 


TABLE  40-2.  Soldier  Characteristics:  Taxonomic  Structure 


Cognitive 

Verbal  ability 

Numerical  ability 

Spatial  ability 

Reasoning 

Mental  processing 

Short  term  memory 

Perceptual  speed/ 
accuracy 

Mechanical  comprehension 

Psychomotor 

Eye-limb  coordination 
Movement  judgment 

Arm-hand  steadiness 
Equilibrium 

Finger  dexterity 

Manual  dexterity 

Control  precision 

MOS 

General 

Characteristics 

Skill  level 

Duty  position 

Pay  grade/date 

Enlistment  date 

Training 

Sex 

Age 

Citizenship 

Attrition  rate 

MOS 

Aptitude/Abilities 

Years  of  education 

Educational  certification 

Mental  category 

AFQT%  score 

TABLE  40-2.  Soldier  Characteristics:  Taxonomic  Structure 


Sensory 

Capabilities 


Hearing 

Stimulus,  thresholds 
Loudness,  pitch, 
Localization 

Aural  distortion 

Auditory  attention 

Speech  clarity 

Vision 

Color  discrimination 

Eye  movements 

Light  sensitivity 

Binocular  vision 

Space  perception 
adaptation 

Peripheral  vision 

Control/display 

Control/display 

integration 

Visual  displays 

Audio  displays 

Controls 

Labeling 

User  system  interface 

Data  entry 

Data  display 

Interactive  control 

Error  messages 

Visual  pattern  recognition 
Dc?ta  nrv'OQcjng  skills 

Human 

Strength 


Ufting/carrying 
Push/pull  forces 
Hand  dynameter  strength 
Control  operational  force 
Static  strength 
Explosive  strength 
Dynamic  strength 
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TABLE  40-2  Soldier  Characteristics:  Taxonomic  Structure 


Anthropometric 

Shirt-sleeved 

Standing  body 
dimensions 

Seated  body 
dimensions 
Depth/breadth 
dimensions 

Circumferences/surface 
Hand/toot  dimensions 
Head/face  dimensions 

A'ctic'NBC  gear 

Sizing  of  controls  & 
access  openings 
Visibility  limitations 
Thermal  stress  factors 

Environmental 

Volume 

Temperature 

Thermal  response 
Tolerances  high/low 
Temp/ventilation  req. 

Illumination 

Impact 

Human  tolerance  limits 
Physiological  response 

Vibration 

Effects  on  performance 
Physiological  effects 
Interaction  with  other 
environmental 
parameters 

Sustained  linear 
and  rotary  acceleration 

Subjective  effects 
Physiological  effects 
Human  tolerances 
Performance  effects 
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TABLE  40-2.  Soldier  Characteristics:  Taxonomic  Structure 


Biomedical 

Noise 

Exposure  limits 

Effects  on  hearing 
Effects  on  communicatio 
Hearing  protection 

Toxicological 

Oxygen  toxicity 

Fuels  and  oxidizers 
Carbon  monoxide 
Threshold  limit  values 

Radiological 

Radiation  detection 
Biological  effects 

Life 

Potable  water 

i 

Daily  requirements  i 

Thermal  interactions 

Support 

Food 

Nutritional  requirements 
Preservation 

Mission  applications 

Sleep  loss/ 
fatigue 

Continuous  operations 
Partial  sleep  loss 

Total  sleep  loss 

Circadian  cycle  effects 
Effects  on  performance 

Respiratory 

environmental 

systems 

Cabin  pressure  failure 
Physiologic  criteria 
Hypoxia  at  high  altitudes 

Other  detailed 

requirements 

from 

Mll-STD-1472 

Ground  workspace 
design 

General 

Standing  operations 
Seated  operations 
Common  working 
positions 

Standard  console  design 
Stairs,  ladders 

Ingress  and  egress 
Surface  colors 
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TABLE  40-2. 


Other  detailed 

requirements 

from 

MIL-STD-1 472 
(cont'd) 


Soldier  Characteristics:  Taxonomic  Structure 


Design  for 
maintainability 

General 

Mounting  of  items 
within  units 

Adjustment  controls 
Accessibility 

Lubrication 

Cases  and  cover 
mounting 

Cases 

Covers 

Access  openings  and 
covers 

Fasteners 

Unit  design  for  efficient 
handling 

Mounting 

Conductors 

Connectors 

Test  points 

Test  equipment 

Failure  indications  and 
fuse  requirements 
Printed  circuit  boards 

Design  of  equipment 
for  remote  handling 

Characteristics  of 
equipment  to  be 
handled  remotely 
Manipulators 

Viewing  equipment 
Illumination 

Portability  and  load 
carrying 
Tracking 

Optical  instruments  and 
related  equipment 


Small  systems 
and  equipment 


TABLE  40-2.  Soldier  Characteristics:  Taxonomic  Structure 


Other  detailed 

requirements 

from 

MIL-STD-1472 

(cont’d) 


Operational  and 
maintenance  vehicles 

General 

Seating 

Controls 

Operating  instructions 
Visibility 

Heating  and  ventilation 
Trailers,  vans  and 
intervehicular 
connections 

Cranes,  materials 
handling  and 
construction 

Automotive  subsystems 

Hazards  and 
safety 

General 

Safety  labels  and 
placards 

Pipe,  hose,  and  tube 
line  identification 

General  workspace 
hazards 

General  equipment- 
related  hazards 

Platforms 

Table  40-3.  Cognitive  Dimensions 


Dimension 

Name 

Description 

Specific 

Measures 

Verbal 

Ability 

Ability  to  understand  written  and, 
in  some  instances,  spoken  language 

ASVAB:  paragraph 
comprehension 

ASVAB:  word  knowledge 

Numeric 

Ability 

Ability  to  perform  arthimetric  operations 
quickly  and  accurately 

ASVAB:  Math  knowledge 
ASVAB:  Arithmetic 
Reasoning 

Project  A:  Number 
memory 

Spatial 

Ability 

Ability  to  identify  objects  that 
have  been  turned  or  rotated,  to  mentally 
assemble  or  disassemble  a  system  into 
consistent  pieces,  and  to  see  figured 
progression 

Project  A:  Assembling 
objects;  object  rotation; 
maze  test;  map  test; 
orientation  test. 

Reasoning 

Ability  to  discover  rules  or  principles 
underlying  relationships  among  objects 
and  to  apply  these  to  solving  problems 

Project  A:  reasoning  test 

Mental 

Processing 

Ability  to  respond  quickly  and  accurately  to 
information,  including  the  ability  to  attend 
simultaneously  to  multiple  stimuli  when 
required 

Project  A:  simple 
reaction  time; 
choice  reaction  time 

Short  Term 
Memory 

Ability  to  recall  recent  information  and 
stimuli. 

Project  A:  short 
term  memory; 
number  memory 

Perceptual  Speec 
and  Accuracy 

Ability  to  notice  similarities  and  differences 
in  visual  stimuli  quickly  and  accurately 

ASVAB:  coding  speed 
Project  A:  perceptual 
speed/accuracy 

Project  A:  target 
identification 

Mechanical 

Comprehension 

Ability  to  understand  mechanical 
operations  and  relationships  and  the 
knowledge  of  automotive,  shop,  and 
electrical  machines,  tools,  and  equipment 
based  on  mechanical  principles 

ASVAB:  mechanical 
comprehension; 
auto/shop  information 
electronic  information 
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Table  40-4.  Psychomotor  Dimensions 


Dimension 

Name 

Description 

Specific 

Measures 

Eye-Limb 

Coordination 

Ability  to  make  steady  and  precise  hand 
and  arm  movements,  particularly  in 
response  to  moving  targets 

Project  A:  Target 
Tracking  1  and  2 

Project  A:  Target  shoot 
Project  A:  Pooled 
movement  time 

Movement 

Judgement 

Ability  to  judge  rates  of  speed 

and  directions  of  moving  objects  and 

predict  their  location  at  future  points  in  time 

Project  A: 

Cannon  shoot 

considerable  information  on  variations  between  different  kinds  of 
military  occupational  specialties  (MOS)  in  cognitive  and 
psychomotor  ability  distributions.  The  abilities  described  must 
however,  be  scaled  relative  to  task  requirements.  In  using  Product 
3,  it  will  be  necessary  to  know  both  how  many  job  incumbents 
possess  various  levels  of  skill  and  also  what  levels  of  skill  are 
required  for  different  types  of  tasks.  Anchors  shall  be  provided  for 
the  cognitive  and  psychomotor  measures  that  relate  otherwise 
abstract  scales  to  specific  task  requirements  (e.g.,  specific  human 
tolerances  for  different  temperature  levels  can  be  used  to  specify 
appropriate  environmental  limits  for  new  systems). 

b.  There  is  also  a  need  to  specify  requirements  such  as  verbal  ability 
levels  on  a  scale  that  has  meaning  for  MANPRINT  specialists. 
Two  approaches  will  be  used  for  anchoring  the  cognitive  and 
psychomotor  dimensions  meaningfully.  First,  the  specific  Project  A 
measures  shall  be  examined  for  marker  items  that  convey  the 
abilities  involved.  As  an  example,  verbal  ability  vocabulary  items 
will  be  found  that  are  known  or  not  known  at  different  levels  of 
ability.  For  spatial  abilities,  examples  of  the  kinds  of  operations 
that  examinees  at  different  levels  can  or  cannot  perform 
consistently  may  be  found.  The  second  approach  to  anchoring  the 
different  cognitive  and  psychomotor  ability  dimensions  will  be  to 
relate  them  directly  to  task  performance.  In  support  of  Product  6 
development,  AIR  has  conducted  a  number  of  analyses  of 
relationships  between  abilities  and  task  performance.  For  each 
cognitive  and  psychomotor  dimension,  tasks  will  be  identified  that 
soldiers  with  different  levels  of  the  relevant  abilities  can  or  cannot 
perform  correctly.  MANPRINT  specialists  can  then  match  new 
tasks  to  these  marker  tasks  in  order  to  determine  potential  design 
constraints  for  the  new  systems.  The  psychomotor  category  also 
includes  five  additional  dimensions  as  shown  in  Table  40-2.  The 
sources  to  develop  these  dimensions  are  identified  in  Table  40-1. 
An  example  of  a  screen  from  the  manual  dexterity  category  is 
presented  in  Figure  40-3. 

40.4.2  MOS  General  Characteristics 

As  a  minimum,  this  category  shall  be  subdivided  as  follows:  skill  level,  pay 
grade/date,  enlistment  date,  training,  sex,  age,  citizenship,  and  attrition  rate. 
Statistics  about  the  present  MOS  skill  levels  shall  be  included  and  these, 
along  with  MOS  attrition  rates,  may  be  used  to  predict  future  percentile  skills 
levels.  The  inclusion  of  pay  grade/date  information,  also  presented  in 
statistical  form,  may  be  used  to  estimate  system  costs.  Enlistment  date  and 
attrition  rates  may  be  used  jointly  to  project  future  MOS  availability.  Training 
data  shall  be  presented  in  terms  of  type  and  time.  Sex,  age,  and  citizenship 
data  shall  be  presented  as  statistical  percentages  and  may  be  used  to 
characterize  the  current  and  projected  MOS  population. 
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AGE  (yeen) 


Number  of  taps  per  second.  Tapping  rate  increases  with  age  up  to  about  18. 
remains  rather  constant  from  18  to  about  50  or  55,  and  then  exhibits  a  slow 
decline  with  older  ages.  Tapping  with  the  forearm  about  the  elbow  joint  is 
fastest,  followed  respectively  by  wrist,  shoulder,  and  finger.  The  right  hand 
taps  faster  than  the  left  (for  right-handed  people),  and  males  tend  to  be 
slightly  faster  than  females. 


Figure  40-3.  Example  Manual  Dexterity  Data  Base  Display 

Screen 
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40.4.3  MOS  Aptitude/Abilities 

As  a  minimum,  this  category  shall  be  subdivided  as  follows:  years  of 
education,  education  certification,  mental  category,  and  AFQT  scores.  All  of 
these  subcategories  shall  be  presented  as  percentiles. 

4C.4.4  Sensory  Capabilities 

As  a  minimum,  this  category  shall  be  subdivided  as  follows:  hearing,  vision, 
control/display,  and  user  system  interface.  The  last  two  categories  are  areas 
which  consider  both  sensory  and  cognitive  human  capabilities,  but  are 
included  within  sensory  capabilities  for  convenience.  Figure  40-4  provides 
an  example  of  a  graphical  entry  in  the  data  base  pertaining  to  eye 
movement. 

40.4.5  Human  Strength 

As  a  minimum,  this  category  shall  be  subdivided  as  follows:  lifting/carrying, 
push/pull  forces,  hand  dynameter,  common  control  operational  force, 
strength  in  relation  to  control,  static  strength,  explosive  strength,  dynamic 
strength,  and  stamina.  Data  for  these  categories  shall  be  derived  from  MIL- 
STD-1472,  the  Human  Factors  Design  Handbook  by  Woodson,  MIL-HDBK- 
759,  and  measurements  from  the  PULHES. 

40.4.6  Anthropometric 

As  a  minimum,  this  section  shall  be  subdivided  as  follows:  shirt-sleeved, 
arctic  gear,  and  nuclear,  biological,  chemical  (NBC)  gear.  The 
anthropometric  data  shall  be  derived  from  MIL-STD-1472,  MIL-HDBK-759A, 
the  Army's  Accession  File,  and  Woodson’s  Human  Factors  Design 
Handbook.  Figure  40-5  shows  two  illustrative  screens.  The  first  is  a  menu  of 
shirt  sleeved  anthropometric  data.  In  this  example,  the  user  has  selected 
standing  body  dimensions.  The  next  screen  presented  would  be  a  graphics 
allowing  the  user  to  select  one  of  ten  dimensions.  In  Figure  40-6  the  user 
has  requested  standing  height.  Percentile  values  in  inches  shall  be 
included  for  the  5th  and  95th  percentile  ground  troops,  aviators,  and  women 
in  accordance  with  MIL-STD-1472  data.  In  addition,  MOS  specific  data  will 
be  provided  as  available.  Figure  40-7  provides  another  screen  example.  In 
this  case,  the  MOS  dimension  for  elbow  rest  height  is  not  available. 
Descriptions  of  the  pertinence  of  the  dimension  to  specific  design  features  is 
provided.  Additional  and  nonduplicative  material  will  be  used  from  MIL- 
HDBK-759A.  All  display  screens  shall  display  ony  one  dimension  (e.g., 
waist  height)  per  screen. 
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Conic  sections  generated  by  eye  movements.  If  the  eye  is  at  the  apex  of  a 
cone,  the  surface  of  the  cone  can  be  imagined  to  be  generated  by  the  line  of 
sight  as  it  tracks  around  a  circular  object.  The  projections  of  the  cone  on  a 
plane  have  different  shapes  depending  on  the  orientation  of  the  cone  and 
the  plane.  By  line  of  sight  is  meant  the  line  projecting  the  fovea,  via  the 
optical  nodal  points  to  the  eye,  to  the  current  point  of  fixation. 


Figure  40-4.  Example  Sensory  Capability  Data  Base  Display 

Screen  -  Eye  Movement 
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tanks  -  Anthropometric  Data  Base 

Shirt  Sleeved 

Standing  body  dimensions 
Seated  body  dimensions 
Depth  and  breadth 
Circumferences  and  surfaces 
Hand  and  foot 
Head  and  face 


Figure  40*5.  Example  Relational  Menu  Query  Screens  - 

Shirt  Sleeved  Dimensions 
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Figure  40-6.  Example  Anthropometric  Data  Base  Display  Screen  - 


Standing  Height 
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Data  B 


This  dimension  is  pertinent  to  the 
establishment  of  armrest  heights. 
Also  provides  a  basis  for 
establishing  the  level  of  writing 
surfaces  and/or  the  approximate 
position  of  the  middle  row  for  a 
keyboard,  the  location  of  a  joystick, 
handle,  control  wheel,  etc. 


Percentile  values  in  inches 


Ground 

Troops 

Aviators 

Women 

6.9 

7.4 

6.4 

11.0 

11.6 

10.6 

Figure  40-7.  Example  Anthropometric  Data  Base  Display  Screen 

Elbow  Rest  Height 
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40.4.7  Environmental 


As  a  minimum,  this  category  shall  be  subdivided  as  follows:  volume, 
temperature,  illumination,  impact,  vibration,  and  sustained  linear/rotary 
acceleration.  Two  examples  from  this  section  are  illustrated:  accelerations 
and  volume. 

a.  The  data  base  section  on  acceleration  will  be  introduced  to  the 
user  with  a  graphics  of  the  coordinate  system  for  accelerations 
influencing  humans.  A  sample  of  this  graphic  is  presented  in 
Figure  40-8.  Textual  data  presented  in  table  format  will  be 
included  as  presented  in  Figures  40-9  and  40-10. 

b.  Crew  volume  requirements,  also  an  element  of  environmental 
within  the  human  characteristics  taxonomy,  shall  include  a  table  of 
minimum  volumes  related  to  three  moderator  variables:  crew  size, 
duration  of  confinement,  and  the  presence  of  aggravating 
conditions  such  as  heat  or  motion  as  illustrated  in  Figure  40-11. 
This  example  includes  only  one  volume  requirement.  Deriving 
data  to  complete  the  table  will  be  a  Phase  III  task. Users  may 
access  this  table  directly,  or  if  they  have  entered  the  appropriate 
information  during  the  design  aid  interface  process,  Product  3  will 
generate  the  specific  requirement  (e.g.,  if  the  user  was  interested 
in  a  tank  with  a  crew  size  of'2,  no  aggravating  conditions,  and 
confinement  of  48  hours.  Product  3  will  not  present  the  table. 
Instead  it  will  present  the  user  with  the  following  statement:  A  two- 
person  crew  expected  to  be  confined  for  up  to  48  hours  should 
have  a  minimum  free  volume  of  125  cu.  ft.  per  person  assuming 
there  are  no  aggravating  conditions  such  as  heat  or  motion). 

40.4.8  Biomedical 

As  a  minimum,  this  category  shall  be  subdivided  as  follows:  noise  levels, 
toxicological,  and  radiological.  The  sources  for  data  in  these  areas  will  be 
MIL-STD-1472,  Bioastronautics  Data  Book,  the  Human  Factors  Design 
Handbook  by  Woodson,  AFR  161-35,  and  AFSC  Design  Handbook  DH  1-3, 
Human  Factors  Engineering.  The  data  shall  be  organized  by  content,  as 
opposed  to  the  data  source,  and  shall  consist  of  textual  and  graphical  data. 

40.4.9  Life  Support 

As  a  minimum,  this  category  shall  include  data  on  potable  water 
requirements,  food  requirements,  and  the  effects  of  sleep  loss  and  fatigue. 
The  sources  for  the  information  on  sleep  loss  and  fatigue  shall  be  derived 
from  various  texts  and  journal  research  as  identified  in  Table  40-11.  The 
majority  of  the  data  on  sleep  loss  and  fatigue  shall  be  textual  and  require 
multiple  screens.  An  example  of  the  data  which  shall  be  included  in  the  data 
base  for  the  area  of  sleep  loss  is  presented  in  Figure  40-12. 
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Figure  40-8.  Example  Data  Base  Display  Screen  for  Coordinate 
System  for  Accelerations  Influencing  Humans 
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Sustained  Linear  Acceleration 


The  fundamental  stimulus  influencing  the  physiological  effects  of 
sustained  acceleration  arises  form  the  effective  increase  in  weight  of  the 
body,  and  particularly  its  fluid  components,  along  the  acceleration  vector. 


1  Gz 

Positive  Acceleration  Effects  (+Gz1 

Equivalent  to  the  erect  or  seated  terrestrial  position. 

2GZ 

Increase  in  weight,  increased  pressure  on  buttocks,  drooping 
of  face  and  soft  body  tissue. 

21/2GZ 

Difficult  to  raise  oneself. 

3-4  Gz 

Impossible  to  raise  oneself,  difficult  to  raise  arms  and 
legs,  movement  at  right  angles  impossible;  progressive 
dimming  of  vision  after  3  to  4  seconds,  progressing  to 
tunnel  vision. 

41/2-6 

Gz 

Diminution  of  vision,  progression  to  blackout  after  about 

5  seconds;  hearing  and  then  consciousness  lost  if  exposure 
continued;  mild  to  severe  convulsions  in  about  50  percent  of 
subjects  during  or  following  unconsciousness,  frequently 
with  bizarre  dreams;  occasionally  paresthesias,  confused 
states,  and  rarely,  gustatory  sensations;  inspiration 
difficult;  loss  of  orientation  for  time  and  space  up  to 

15  seconds  past  acceleration. 

1  Gz 

Negative  Acceleration  Effects  f-Gzl 

Unpleasant  but  tolerable  facial  suffusion  and  congestion. 

-2  to  -3 
Gz 

Severe  facial  congestion,  throbbing  headache;  progressive 
blurring,  graying,  or  occasionally  reddening  of  vision 
after  5  seconds;  congestion  disappears  slowly,  may  leave 
petechial  hemorrhages,  edematous  eyelids. 

-SQz 

Five  seconds,  limit  of  tolerance,  rarely  reached  by  most 
subjects. 

Figure  40-9.  Example  Data  Base  Display  Screen  for  Sustained 
Positive  and  Negative  Acceleration  Effects 
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Forward  Acceleration  Effects  (+Gx) 

2-3  G 

X 

Increased  weight  and  abdominal  pressure;  progressive  slight 
difficulty  in  focusing  and  slight  spatial  disorientation, 
each  subsiding  with  experience;  2  G  tolerable  at  least  24 
hours,  4  Gx  up  to  at  least  60  minutes. 

3-6  Gx 

Progressive  tightness  in  chest  (6  G  ,  5  minutes),  chest 
pain,  loss  of  peripheral  vision,  difficulty  in  breathing  and 
speaking,  blurring  of  vision,  effort  required  to  maintain 
focus. 

6-9  Gx 

Increased  chest  pain  and  pressure;  breathing  difficult,  with 
shallow  respiration  from  position  of  nearly  full 
inspiration;  further  reduction  in  peripheral  vision, 
increased  blurring,  occasional  tunneling,  great 
concentration  to  maintain  focus;  occasional  lacrimation; 
body,  legs,  and  arms  cannot  be  lifted  at  8  G  *  head  cannot 
be  lifted  at  9  Gx- 

9-12 

Gx 

Breathing  difficulty  severe;  increased  chest  pain;  marked 
fatigue;  loss  of  peripheral  vision,  diminution  of  central 
acuity,  lacrimation. 

15  Gx 

Extreme  difficulty  in  breathing  and  speaking;  severe 
vise-like  chest  pain;  loss  of  tactile  sensation;  recurrent 
complete  loss  of  vision. 

Figure  40-10.  Example  Data  Base  Display  Screen  for  Sustained 
Forward  Acceleration  Effects 
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*  heat,  motion,  etc. 
**  To  Be  Supplied 


Figure  40-11.  Example  Data  Base  Display  Screen  Text 
for  Crew  Volume  Requirements 
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Sleep  Loss  Effects  on  Performance 
Type  of  Tasks 

1 .  Activities  that  demand  a  high  level  of  alertness  of  complex  perceptual/motor 
activity,  such  as  moving  surveillance  and  some  driving  tasks,  are  the  most  sensitive 
to  the  adverse  effects  of  sleep  loss. 

2.  Work-paced  tasks  (e.g.,  those  whose  pace  is  driven  by  the  work)  such  as 
watching  a  radar  screen,  monitoring  radio  communications,  or  receiving 
instructions,  are  more  subject  to  the  effects  of  sleep  loss  than  self-paced  tasks. 

3.  Sleep  deficit  effects  will  be  more  apparent  on  newly  acquired  skills. 

Motivation 

In  general,  high  motivation  can  reduce  the  effects  of  sleep  loss.  Although,  in  cases 
of  extremely  high  stress,  such  as  life-threatening  situations,  performance  of  most 
people  will  deteriorate  drastically. 

Personality  Factors 

There  is  evidence  that  introverts  can  tolerate  loss  of  sleep  better  than  extroverts. 
Performance  on  a  pursuit  tracking  task  after  60  hours  without  sleep  has  been 
predicted  by  scores  on  the  Barron  Ego  Strength  Scale. 

Diurnal  Cycle 

Sleep  deprivation's  deleterious  effect  on  performance  is  particularly  detrimental 
between  the  hours  of  0300  and  0600. 

Task  Duration 

There  is  a  noticeable  decrease  in  the  ability  to  focus  on  a  task  for  more  than  a  brief 
period.  Dividing  attention  between  two  or  more  tasks  becomes  difficult. 

Work/Rest  Cycles 

Minimum 

A  work  schedule  consisting  of  4  hours  on  and  4  hours  off  has  been  found  to  be 
capable  of  sustaining  minimum  vigilance  and  cognitive  performance  for  continuous 
combat. 

Recommended 

The  recommended  work/rest  cycle  is  6  hours  on  and  6  hours  off. 

Recovery 

_ Upon  awakening,  it  takes  1  1/2  hours  to  return  to  a  cognitively  normal  state. 


Figure  40-12.  Alphanumeric  Data  Base 
Example  of  Sleep  Loss  Related  Soldier  Characteristics 
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40.5  Other  Data  Base  Features 


40.5.1  Glossary 

The  Product  3  soldier  characteristic  data  bases  shall  contain  a  glossary  of 
soldier  characteristic  data  terms.  Glossary  terms  appearing  in  display 
screens  shall  be  highlighted.  The  user  shall  be  able  to  move  the  cursor  to 
the  highlighted  term  and  execute  an  appropriate  command.  For  example, 
the  expression  "absorbed  power"  in  Figure  4C-12  v;cu!d  be  highlighted. 
When  requested,  the  definition  would  automatically  appear  within  a  pop-up 
window  as  shown. 

40.5.2  Reference  Table 


Every  entity  in  the  data  base  (i.e.;  textual  paragraphs  graphics,  tables,  etc.) 
shall  have  an  accompanying  identifier.  Using  the  cursor  key,  a  user  may 
move  to  the  identifier  and  execute  an  appropriate  command.  The  source 
reference  for  the  entity  shall  then  appear  automatically  in  the  same  pop-up 
window  as  that  used  for  term  definitions. 


Vibration  Tolerances 

ReactionJims 

Vibration  does  not  typically  affect  human  reaction  time.  When  reaction 
time  is  affected  during  or  following  vibration  exposure,  only  several 
one-hundredths  of  a  second  are  added  to  the  static  base  reaction  time, 
normally  0.02  to  0  05  seconds.  Increases  in  vibration  intensity  or 
duration  do  not  pr 

Visual  Impairmen 

Visual  impairment 
situation.  In  gene 
visual  performanc 
error  when  motior 
reduction  in  the  z- 
some  indication  tf 
result  in  larger  err 
mesure  central  nt 
pattern  recognitio 
vibration. 


Absorbed-P.ower 

Absorbed  power  is  a  function 
of  force,  velocity,  and  time 
with  weighted  frequencies. 

The  upper  limit  of  6-watts 
is  approximately  equal  to 
0.20  Root  Mean  Square  (RMS)  g's. 
This  limit  has  been  established 
through  testing  of  human  subjects. 


Visual  blurring  occ 
for  a  40  minute  e> 


Maximum  Levels 


ime. 


ion/task 
jental  to 
pe  visual 

f.  There  is 
:-axis  may 
>that 

itoring,  and 
Ition  during 


1-1000  Hz, 


Vehicles  should  be  designed  so  as  not  to  impose  vibration  on  its 
occupants  in  excess  of  6-watts  of  absorbed  power .  Beyond  this  level 
there  is  a  risk  of  human  injury  and  cargo/vehicle  damage. 


Figure  40-13.  Example  of  Executed  Data  Base  Glossary  Display  Screen 
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APPENDIX  V.  DATA  BASE  DESIGN  SPECIFICATION 

50.1  Overview  of  the  REVELATION  Data  Base  Environment 

Characteristics  of  the  Product  3  data  base  shall  be  compatible  with  the 
REVELATION  data  base  management  system.  Figure  50.1  shows  the 
flexible  structure  of  the  REVELATION  data  base  management  system.  The 
REVELATION  data  base  management  system  shall  provide  the  capability  to 
organize  information  about  soldier  characteristics  into  accounts,  files,  and 
records.  Preliminary  estimates  of  storage  requirements  for  all  data  base 
records,  dictionary  files,  and  program  files  comprising  the  REVELATION 
system  (and  external  files  including  essential  MS-DOS  and  software  tools  to 
be  stored  in  the  initial  configuration  of  the  Product  3  data  base)  are  listed  in 
Table  50-1 . 

50.1.1  REVELATION  Data  Base  Management  System 

a.  REVELATION  is  a  dictionary-driven  system.  Dictionaries  defining 
all  elements  of  accounts,  files,  records,  and  data  fields  in  the  data 
base  (and  elements  of  menus,  windows,  and  help  messages 
defining  user-friendly  interfaces)  will  also  be  stored  in  the  data 
base.  The  system  dictionary  shall  specify  names  of  object  code 
and  source  code  files  written  in  the  Revelation  R/BASIC  language 
(a  full-featured  extension  of  standard  Basic  compatible  with  data 
base  management  and  multi-user  network  operations).  Names  of 
source  code  files  and  object  code  files  in  Revelation's  Terminal 
Command  Language  (using  compact  commands  to  provide  short 
cuts  for  sophisticated  users,  bypassing  menu  and  prompt 
windows)  shall  be  stored  in  the  data  base. 

b.  To  the  host  computer’s  MS-DOS  operating  system,  Product  3 
REVELATION  files  will  look  like  any  other  application  that  builds 
and  maintains  disk  files.  REVELATION  will  be  transparent  to  the 
underlying  operating  system  which  actually  manages  physical 
transfers  of  data  between  internal  memory  and  external  disks. 
REVELATION  will  ride  on  top  of  the  MS-DOS  operating  system, 
maintaining  its  own  native  operating  environment,  including  its 
own  logical  file  names  for  dictionary  files,  data  files,  and 
application  program  files. 

c.  REVELATION  shall  interface  with  MS-DOS  to  maintain  its  own 
files  and  to  store  and  retrieve  external  object  code  files.  External 
code  files  (e.g.  routines  in  Microsoft  "C"  and  assembly  language 
and  off-shelf  or  newiy  built  programs  to  construct  "on-the-fly" 
graphic  diagrams,  etc.)  can  be  called  directly  from  within 
REVELATION  to  control  special  functions  or  hardware  interfaces 
(e.g.,  mouse,  page  scanner,  graphic  digitizer,  etc.). 
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ACCOUNT  3  NAME  (ACCOUNT  2  SYNONYM)  4  USER  PASSWORD 


Figure  50-1 :  REVELATION  DBMS  Environment 
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Table  50-1 :  Product  3  Data  Base  Storage  Estimates 


Type  of  Data  Base  File _ 

REVELATION  System  and  MS-DOS  Files 
Product  3  Program  Files: 


DAI  Object  Code  100  Kb 
KAI  Object  Code  35  Kb 
SPR  Object  Code  25  Kb 
Training/Help  Object  Code  40  Kb 
Analysis  Object  Code  110  Kb 


Product  3  Bic-Mapped  Craphics  Files  (400  pics) 
Product  3  Soldier  Characteristics  Files 
(See  Attached  Tables) 

*  Product  3  Source  Code  Files  (8  x  Object  Code) 

*  Microsoft  C  and  80286  Assembler 


Megabyte 

2.650 

.310 


3.200 

2.125 

2,480 

1.975 


ESTIMATED  TOTAL  DISK  STORAGE  12.740 

*  Note:  Source,  C,  and  Assembler  files  could  be  stored 
off-line  on  removable  cartridge. 
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50.1.2  Data  Base  User  Accounts 

a.  Each  REVELATION  account  shall  contain  its  own  list  of  files,  its 
own  data  dictionary  defining  names  of  files,  records,  and  fields, 
and  a  set  of  files  defining  a  user-friendly  environment  consisting  of 
menus,  pop-up  windows,  and  associated  context-sensitive  HELP 
messages  to  prompt  and  guide  the  user  in  data  selection  and 
report  formatting.  Each  account  can  have  several  synonymous 
names,  and  each  name  can  have  its  own  unique  LOG-ON 
password.  Passwords  shall  prevent  unauthorized  access  to  data 
or  to  potentially  destructive  file  maintenance  programs.  They  can 
be  encrypted  if  desired  and  changed  periodically  to  maintain  data 
base  security. 

b.  Because  most  users  will  use  the  same  files  but  some  system  files 
will  be  used  only  by  the  system  manager  for  file  maintenance,  it  is 
anticipated  that  at  each  MANPRINT  Product  3  site  two  or  more 
accounts  may  be  established,  each  with  its  own  unique  password. 
One  account  may  be  for  the  local  system  manager  responsible  for 
periodic  file  maintenance  and  coordination  of  import/export  file 
processing  to  receive  from  or  send  files  to  other  MANPRINT 
decision  aid  systems  (e.g.,  Product  6).  Other  password-controlled 
accounts  may  be  set  up  for  local  users.  Users  may  ail  use  the 
same  password  and  same  account.  Account  name  synonyms 
could  simply  be  the  user  surnames,  or  some  other  identification  of 
the  person,  local  branch  office,  etc.  If  needed,  separate  accounts 
and  passwords  may  be  set  up  for  specialized  users  who  do  not 
want  o*"  need  access  to  all  files.  As  no  TEMPEST  requirements 
have  been  specified  for  the  Product  3  host  hardware  system,  it  is 
not  expected  that  any  data  base  files  will  contain  classified 
information.  Creation  of  new  accounts  and  passwords  shall  be  a 
simple  menu-driven  procedure  with  its  own  built-in  prompts,  easily 
accomplished  within  a  few  minutes  by  an  authorized  user  or  local 
system  manager. 

50.1.3  Data  Base  File  Management  Systems 

a.  REVELATION  supports  two  types  of  files.  Changing  an  existing 
file  from  one  type  to  the  other  shall  be  easily  accomplished  with  a 
simple  command  REMAKEFILE,  so  design  decisions  are 
reversible.  The  only  penalty  for  changing  file  type  is  the  time  to 
reformat  the  file  and  its  associated  data  dictionary.  Choice  of  file 
type  shall  be  determined  by  how  the  files  will  be  used,  how  their 
records  will  be  indexed,  and  whether  the  files  will  be  shared  by 
simultaneous  users  in  a  local  area  network.  The  two  types  of 
internal  files  which  can  be  maintained  with  REVELATION'S  two 
file  management  systems  are  ROS  files  and  LHASH  files.  Both 
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types  of  files  shall  provide  for  an  unlimited  number  of  variable 
length  records  with  a  nominal  maximum  of  32,000  fields  per 
record.  ROS  files  shall  require  estimates  of  file  size,  but  those 
estimates  will  not  limit  growth  of  the  file  beyond  the  estimated  size. 
LHASH  files  shall  not  require  entry  of  estimated  file  sizes.  Both 
types  of  files  shall  have  the  capability  to  grow  up  to  the  limits  set  by 
the  physical  capacity  of  the  disk  storage  media.  Both  of  the 
associated  file  management  systems  shall  interface  with  MS-DOS 
in  a  manner  which  is  transparent  to  the  user.  Users  shall  not  have 
to  be  trained  to  become  familiar  with  the  MS-DOS  command 
language. 

50.1.3.1  ROS  Files 

This  type  file  will  be  for  use  at  a  single-user  terminal  where  files  are  NOT 
shared.  Maximum  file  size  is  nominally  5  Megabytes,  but  access  is  slow  and 
inefficient  for  ROS  files  over  two  Kilobytes  because  record  retrieval  time 
grows  with  file  size.  ROS  file  access  is  most  efficient  for  files  under  50 
Kilobytes.  ROS  files  shall  be  employed  for  small  internal  work  files  created 
or  deleted  by  software  components  when  and  if  ROS  files  provide  faster 
response  to  user  inputs  and  the  functions  being  performed  do  not  need  the 
dynamic  cache  and  file  size  management  provided  for  LHASH  files  as 
described  below. 

50.1.3.2  LHASH  Files 

a  This  type  file  is  maintained  by  using  the  "linear  hashing" 
technique,  proven  to  be  highly  efficient  because  access  time  is 
independent  of  file  size.  LHASH  files  can  be  shared  by  local  area 
network  (LAN)  users,  employing  a  record  LOCK/UNLOCK 
semaphore  system  to  prevent  two  users  from  trying  to  access  or 
modify  the  same  record.  For  local  or  wide  area  networks  using 
packet  technology,  data  frame  size  is  adjustable  over  the  range 
256  to  10,240  bytes,  with  a  default  of  1 ,024  bytes  (1  Kilobyte).  At 
single-user  terminals,  small  data  frame  sizes  will  make  it  easier  to 
find  and  fix  minor  data  entry  errors  in  dictionary,  data,  or  output 
report  files. 

b.  The  LHASH  file  management  system  is  superior  to  the  ROS  file 
management  system  in  several  other  ways  which  make  it  the  best 
choice  for  most  MANPRINT  Product  3  data  base  files.  LHASH  file 
size  can  be  automatically  expanded  or  contracted  when  groups  of 
records  are  added  or  deleted.  This  dynamic  file  size  adjustment 
shall  prevent  system  crashes  of  the  type  which  can  occur  in 
systems  using  fixed  record  sizes  for  files  and  overflow  record 
buffers  or  a  variety  of  intermediate  index  files.  When  necessary  or 
desirable,  dynamic  file  size  adjustment  may  be  restricted  or 
disabled  for  static  files  subject  to  little  or  no  change  in  size  (i.e., 
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data  dictionary  files,  which  normally  would  expand  or  contract  only 
when  new  fields  are  added  or  obsolete  data  fields  are  deleted 
from  the  definition  of  a  record). 

c.  On  a  single-user  terminal,  the  LHASH  file  management  system 
shall  have  the  capability  to  maintain  a  dynamic  cache  of  up  to  64 
Kilobytes  containing  up  to  20  data  record  "slots."  The  actual  size 
of  record  slots  in  the  cache  (and  the  number  of  records  storable  in 
the  cache)  shall  be  adjusted  dynamically  based  on  the  variable 
size  of  the  largest  record  in  a  group.  The  cache  and  hash 
techniques  will  minimize  record  access  time  and  requirements  for 
periodic  sorting  and  re-indexing  of  large  files,  which  otherwise 
would  consume  significant  amounts  of  time  and  disk  space. 
Where  applicable,  alternate  indexing  schemes  may  be  applied  to 
a  single  file  (e.g.  cross-referencing,  binary  tree  search,  etc.) 

d.  Because  of  its  higher  efficiency,  the  LHASH  file  management 
system  shall  be  used  for  most  Product  3  dictionary  and  data  base 
files  and  all  output  files  built  in  response  to  user  commands  (e.g. 
output  of  the  Search  Process  Record  component). 

e.  Networking  is  not  presently  required  for  Product  3  single-user 
applications.  However,  the  proven  compatibility  of  the 
REVELATION  LHASH  file  management  system  with  a  variety  of 
network  protocols  (IBM  token  ring,  3MCOM  ETHERNET,  etc.)  will 
leave  open  a  door  to  possible  future  growth.  Network  protocols 
permit  several  terminals  to  share  simultaneous  access  to  a  single 
data  base  on  the  host  system  hard  disk.  For  example, 
simultaneous  users  could  be  two  or  more  Product  3  users  and  a 
Product  6  user  needing  access  to  files  not  duplicated  within  the 
Product  6  environment,  or  some  other  combination  of  users 
connected  to  the  Product  3  host  system  in  a  hard-wired  LAN  (or 
via  telephone  data  links  and  modems  in  a  wide-area  network 
(WAN)  with  or  without  packet  switching).  If  LAN/WAN  operation 
can  be  shown  to  enhance  overall  efficiency  and  economy  in 
operation  and  maintenance  of  the  six  MANPRINT  decision  aids, 
formation  of  an  Interface  Control  Working  Group  (ICWG)  to 
coordinate  hardware  and  software  interfaces  and  develop 
Interface  Control  Drawings  (ICDs)  would  be  required  early  in 
Phase  III. 

50.1.4  Data  Base  Record  and  Field  Structures 

a.  The  primary  data  structures  for  records  stored  in  the  MANPRINT 
Product  3  data  base  shall  be  open-ended  dynamic  arrays,  as 
illustrated  in  Figure  50-2.  In  the  REVELATION  data  base 
management  system  environment,  all  records  shall  be  stored  in  a 
dynamic  array  as  a  string  of  ASCII  characters  punctuated  with 
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Figure  50-2:  Dynamic  Array  Structu 


delimiters.  A  delimiter  shall  mark  the  end  of  each  data  element  in 
a  dynamic  array  in  a  fashion  similar  to  punctuation  marks  in 
English  sentences  (comma  at  the  end  of  a  dependent  phrase, 
semi-colon  at  the  end  of  an  independent  clause,  and  period  at  the 
end  of  sentence).  The  five  types  of  delimiters  to  be  used  in 
REVELATION'S  dynamic  array  structure  are  listed  below  with  their 
printed  symbols  and  non-printing  ASCII  codes: 


DELIMITER 

SYMbOL 

AbOil 

Field  Mark 

@FM 

254 

Value  Mark 

@VM 

253 

Sub-Value  Mark 

@SVM 

252 

Text  Mark 

@TM 

251 

Sub-Text  Mark 

@STM 

250 

b.  The  maximum  size  of  a  record  in  a  REVELATION  dynamic  array 
shall  be  64  kilobytes,  including  delimiters.  Each  field  within  a 
record  shall  be  separated  by  a  field  mark.  Fields  may  contain 
multiple  values  (e.g.,  three  types  of  military  weapon  systems 
maintained  by  personnel  with  a  single  MOS).  Thus,  a  single 
record  may  represent  a  variety  of  one  to  many  (master/detail  or 
header/trailer)  relations  and  many  to  one  (predecessor/successor) 
relations.  The  first  field  in  a  record  shall  always  be  the  key  to  that 
record,  but  it  too  can  be  multi-valued,  thus  providing  secondary 
indexes  to  the  same  record.  Secondary  indexes  will  provide  a 
flexible  method  for  cross-indexing  data  in  separate  files  without 
creation  and  maintenance  of  intermediate  cross-index  files.  This 
will  not  preclude  use  of  small  cross-reference  text  files  with  a 
common  key  to  simplify  maintenance  of  acronyms,  abbreviations 
and  technical  terms  some  users  may  not  know,  as  illustrated  in  the 
preliminary  set  of  data  files  listed  in  Section  50.3  below. 

c.  Within  a  multi-valued  numeric  field,  each  value  shall  be  delimited 
by  a  value  mark.  In  a  logical  field  with  single  or  multiple  numeric 
values,  sub-values  will  be  entered  which  sum  to  a  total  equal  to 
the  value  (e.g.,  in  a  dynamic  array  of  demographic  characteristics 
of  soldiers,  one  field  might  contain  two  values,  one  for  the  number 
of  soldiers  whose  native  language  is  English  and  another  for 
soldiers  whose  native  language  is  not  English.  For  the  latter,  sub¬ 
values  could  be  entered  for  the  numbers  of  soldiers  whose 
native  language  is  Spanish,  Korean,  or  other  non-English 
language).  All  sub-values  will  be  delimited  with  a  sub-  value 
mark. 
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d.  An  alphabetic  text  string  in  a  single  field  may  also  be  divided  into 
sub-fields  using  text  mark  and  sub-text  mark  delimiters,  permitting 
access  to  either  the  whole  text  string  or  two  or  more  portions  of  the 
text  string.  This  feature  shall  to  be  used  to  access  keywords  in 
titles  of  weapon  system  functions  and  tasks  for  which  performance 
measures  exist  or  become  available. 

The  flexibility  of  REVELATION'S  dynamic  record  structures  will  be  highly 
suitable  for  the  Product  3  data  base,  where  names  and  values  for  measures 
of  physical  and  cognitive  characteristics  of  sub-populations  of  soldiers  (and 
performance  measures  for  groups  of  tasks  under  a  variety  of  conditions)  may 
not  be  known  initially,  but  can  easily  be  inserted  when  they  become 
available. 

50.2  User  Menus  and  Windows 

a.  The  new  (August,  1987)  version  of  the  REVELATION  data  base 
management  system  produced  by  COSMOS  is  significantly 
different  from  the  version  used  to  build  a  Product  3  prototype 
demonstration  during  the  Phase  I  effort.  In  contrast  to  the  older 
version  of  REVELATION,  which  relied  on  harder-to-learn  Terminal 
Control  Language  (TCL)  statements,  the  Advanced  REV^i  ATiON 
DBMS  software  package  provides  a  user-friendly  face.  Existing 
off-the-shelf  software  provides  a  well-defined  set  of  over  1 00  easy- 
to-use  menus,  popup  windows,  and  context-sensitive  HELP 
messages  for  functions  routinely  performed  with  any  data  base 
system  (display,  list,  report,  browse,  etc.).  The  tree  structure  of 
Advanced  REVELATION  menus  is  illustrated  in  Figure  50-3. 

b.  Most  users  of  Product  3  will  follow  the  main  branch  labelled 
"ACCESS"  in  Figure  50-3,  accessing  the  soldier  characteristics 
data  base  via  menus  and  popup  windows  to  select  information  to 
be  included  in  reports.  The  Design  Aid  Interface  component 
described  in  the  body  of  the  Product  3  specification  shall  interface 
with  the  underlying  REVELATION  data  base  dictionary  of 
accounts,  files,  and  record  structures  to  provide  a  set  of 
customized  access  paths  and  display,  list,  and  report  generation 
functions.  The  Design  Aid  Interface  component  shall  also  provide 
a  customized  set  of  paths  to  the  EXIT  branch  to  assure  an  orderly 
termination  of  a  user  session. 

c.  At  each  user  site,  a  local  user  designated  as  the  site’s  user 
account  manager  will  follow  the  MANAGEMENT  branch  shown  on 
Figure  50-3  to  set  up  or  delete  a  password-controlled  account  for 
each  user.  Sophisticated  users  may  occasionally  use  the  TOOLS 
branch  illustrated  in  Figure  50-3  for  import/export  of  templates  and 
data  sets  stored  in  personal  work  files  compatible  with  other 
IBM/PC  software  packages  (Lotus  1-2-3,  dBase  III,  etc.).  The  ARI 
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Figure  50-3:  Advanced  REVELATION  Menu  Structure 
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system  manager  and  each  site's  user  account  manager  will 
periodically  use  the  TOOLS  branch  for  system  maintenance 
functions.  Use  of  some  of  the  potentially  destructive  functions  on 
the  TOOLS  list  and  all  of  the  functions  on  the  DESIGN  menus 
branch  shown  in  Figure  50-3  can  be  restricted  to  ARI  staff 
members  (MANPRINT  system  manager,  programmers,  or  research 
staff  members  familiar  with  system  capabilities  and  procedures  for 
data  base  maintenance  and  modification). 

d.  For  users  unfamiliar  with  use  of  a  mouse  control,  the  Advanced 
REVELATION  system  shall  provide  a  thoroughly  debugged  set  of 
menu  select  and  sequence  control  functions  using  cursor  keys 
and  function  keys.  Product  3  applications  software  will  include  a 
mouse  handler  (compatible  with  the  IBM/PC  Microsoft  Mouse 
Driver  interface  specification)  and  user-friendly  features 
compatible  with  the  REVELATION  system.  Product  3  mouse 
applications  software  developed  in  Phase  III  shall  minimize 
keystrokes  required  from  the  user.  Knowledgeable,  trained  users 
and  system  programmers  familiar  with  TCL  command  syntax  shall 
always  have  the  option  to  enter  and  execute  keyboard  commands, 
bypassing  the  protection  and  help  available  by  using  menus  and 
windows.  Where  built-in  TCL  error  messages  are  judged 
inadequate,  system-level  alert  messages  shall  be  created  in 
Phase  Ifl  to  prohibit  or  warn  a  user  attempting  to  command  an 
irreversible  action  (e.g.  DELETE  an  essential  system  data  file  or 
dictionary  file). 

50.3  Preliminary  Design  of  Data  Base  File/Record/Field 
Structures 

Tables  50-2  through  50-12  provide  preliminary  designs  for  essential  data 
files  showing  record  structure  and  the  descriptive  dictionary  name,  size, 
type,  and  comments  for  each  data  field.  Notes  indicate  the  purpose  of  each 
file  and  source(s)  of  data.  Test  data  sets  will  be  generated  from  the  Project  A 
data  base  at  AIR's  Washington  office,  constructed  by  AIR’s  Bedford  Systems 
Division  from  human  engineering  standards,  specifications,  and  research 
documents,  or  derived  from  the  Army  Accession  and  Enlisted  Personnel  files 
available  at  the  Army  Research  Institute  MANPRINT  program  office. 
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Table  50-2.  Main  Soldier  Populations  File 


(One  Record  for  all  MOSs,  each  CHF,  each  PM0S3  code,  each  PM0S5  code 
(and  one  record  for  each  PM0S5  +  Additional  Skill  Identifier  and 
(where  applicable  1-character  flag  *  —  males  only/prefix  or  suffix 


Field  Dictionary  Name  Size  Values  Total  Type  Comments 


1 

Primary  MOS+ASI 

8 

1 

2 

Population  Size 

6 

1 

3 

Males,  Females 

2 

2 

A 

Age  Group 

2 

12 

5 

Years  of  Service 

2 

12 

6 

Pay  Grade 

2 

14 

7 

Racial  Group 

2 

6 

8 

Ethnic  Group 

2 

22 

9 

Years  of  School 

2 

12 

10 

Educ . Certificate 

2 

16 

11 

College  Major 

2 

32 

12 

Citizenship 

2 

5 

13 

Weight  Lift 

2 

7 

14 

Physical  Category 

2 

6 

15 

Physical  Stamina 

2 

4 

16 

Upper  Extremities 

2 

3 

17 

Lower  Extremities 

2 

3 

18 

Hearing 

2 

4 

19 

Eyesight 

2 

2 

20 

S  Senses 

2 

3 

21 

Native  Language 

2 

2 

22 

Enlistment  Term 

2 

7 

23 

Army  Service  Type 

2 

5 

24 

AFQT  Category 

2 

9 

25 

AFQT  Score 

2 

10 

26 

Clerical  Aptitude 

2 

10 

27 

Combat  Aptitude 

2 

10 

28 

Elect .Aptitude 

2 

10 

29 

Fid . Art . Aptitude 

2 

10 

30 

GenMaint. Aptitude 

2 

10 

31 

Gen . Tech . Aptitude 

2 

10 

32 

Mech.  Aptitude 

2 

10 

33 

FoodSvc  Aptitude 

2 

10 

34 

PMOS  SQT  Score 

2 

10 

35 

SurvComm . Ap t i tude 

2 

10 

36 

Tech . Aptitude 

2 

10 

Record  Size- 
Number  of  Records- 
Est.  File  Size- 


8 

C 

Record  Key 

6 

N 

Number  Holding  MOS 

4 

N 

% 

of 

Population 

24 

N 

% 

in 

3 -Year  Groups 

24 

N 

% 

in 

3-Year  Groups 

20 

N 

% 

in 

each  Pay  Grade 

12 

N 

% 

in 

each  Race  Group 

44 

N 

% 

in 

each  Category 

24 

N 

% 

in 

each  Category 

32 

N 

% 

in 

each  Category 

64 

N 

% 

in 

each  Category 

10 

N 

% 

in 

each  Category 

14 

N 

% 

in 

each  Category 

12 

N 

% 

in 

each  Category 

8 

N 

% 

in 

each  Category 

6 

N 

% 

in 

each  Category 

6 

N 

% 

in 

each  Category 

8 

N 

% 

in 

each  Category 

4 

N 

« 

in 

each  Category 

6 

N 

% 

in 

each  Category 

4 

% 

English/Other 

14 

N 

% 

in 

each  Category 

10 

N 

% 

in 

each  Category 

18 

N 

% 

in 

each  Category 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

20 

N 

% 

in 

each  Decile 

622 

1000 

622,000 
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Table  50-2.1.  Project  A  Soldier  Task  Performance  "CV"  File 

(One  Record  all  MOS ,  one  record  nine  MOS  in  CV  Subpopul^tion) 


£ield 

Dictionary  Name 

Size  valves 

Total  Type 

Comments 

1 

Primary  MOS 

5 

1 

5 

C 

Record  Key 

2 

Population  Size 

6 

1 

6 

N 

Number  Holding  MOS 

3 

Males,  Females 

2 

2 

4 

N 

%  of  Population 

4 

Age  Croup 

2 

12 

24 

N 

%  in  3 -Year  Groups 

5 

Years  of  Service 

2 

12 

24 

N 

%  in  3-Year  Groups 

6 

Pay  Grade 

2 

14 

20 

N 

%  in  each  Pay  Crade 

7 

Racial  Group 

2 

6 

12 

N 

%  in  each  Race  Croup 

8 

Ethnic  Group 

2 

22 

44 

N 

%  in  each  Category 

9 

Years  of  School 

2 

12 

24 

N 

%  in  each  Category 

10 

Educ .Certificate 

2 

16 

32 

N 

%  in  each  Category 

11 

College  Major 

2 

32 

64 

N 

%  in  each  Category 

12 

Citizenship 

2 

5 

10 

N 

t  in  each  Category 

13 

Weight  Lift 

2 

7 

14 

N 

%  in  each  Category 

14 

Physical  Category 

2 

6 

12 

N 

%  in  each  Category 

15 

physical  Stamina 

2 

4 

8 

N 

%  in  each  Category 

16 

Upper  Extremities 

2 

3 

6 

N 

%  in  each  Category 

17 

Lower  Extremities 

2 

3 

6 

N 

%  in  each  Category 

18 

Hearing 

2 

4 

8 

N 

%  in  each  Category 

19 

Eyesight 

2 

2 

4 

N 

%  in  each  Category 

20 

S  Senses 

2 

3 

6 

N 

%  in  each  Category 

21 

Native  Language 

2 

2 

4 

%  English/Other 

22 

Enlistment  Term 

2 

7 

14 

N 

%  in  each  Category 

23 

Army  Service  Type 

2 

5 

10 

N 

%  in  each  Category 

24 

AFQT  Category 

2 

9 

18 

N 

%  in  each  Category 

25 

AFQT  Score 

2 

10 

20 

N 

%  in  each  Decile 

26 

Clerical  Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

27 

Combat  Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

28 

Elect. Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

29 

Fid . Art . Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

30 

GenMaint. Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

31 

Gen . Tech . Ap  t i tude 

2 

10 

20 

N 

%  in  each  Decile 

32 

Mech.  Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

33 

FoodSvc  Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

34 

PMOS  SQT  Score 

2 

10 

20 

N 

%  in  each  Decile 

35 

SurvComm .Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

36 

Tech. Aptitude 

2 

10 

20 

N 

%  in  each  Decile 

Project  A  Constructs  for  MANPRINT  Product  3 


37 

A:Verbal  Ability 

2 

10 

20 

N 

% 

in 

each 

Decile 

38 

A:Numeric  Ability 

2 

10 

20 

N 

« 

in 

each 

Decile 

39 

A: Spatial  Ability' 

2 

10 

20 

N 

% 

in 

each 

Decile 

40 

A:Reasoning  Abil. 

2 

10 

20 

N 

« 

in 

each 

Decile 

41 

A:Ment. Processing 

2 

10 

20 

N 

% 

in 

each 

Decile 

42 

A: ShortTerraMeaory 

2 

10 

20 

N 

« 

in 

each 

Decile 

43 

A:Percept. Speed 

2 

10 

20 

N 

% 

in 

each 

Decile 

44 

A:Mech.Comprehen. 

2 

10 

20 

N 

% 

in 

each 

Decile 

45 

ArFye-Lirab  Coord. 

2 

10 

20 

N 

% 

in 

each 

Decile 

46 

A  rMovementJudgrat . 

2 

10 

20 

N 

t 

in 

each 

Decile 

Record  Size- 

819 

Number  of  Records- 

10 

Esc . 

File  Size- 

8.190 
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Table  50-2.1.1.  Project  A  Soldier  Task  Performance  "CV"  File 


(One  Record  all  MOS ,  one  record  nine  MOS  in  CV  Subpopulation) 


Field  Dictionary  Name 

Size  Values 

Total  Type 

Comments 

1  Primary  MOS 

8 

1 

8 

C 

Record  Key 

2  A:Task-l  Score 

2 

10 

20 

N 

%  in  each  Category 

18  A:Task-18  Score 

2 

10 

20 

N 

%  in  each  Category 

19  Last  Change 

Date 

8 

D 

YY/MM/DD  Format 

Record  Size- 

348 

Number  of  Records- 

10 

Est.  File  Size- 

3,480 

Table  50-2.1.2:  Project  A  Soldier  Task  Identification  "CV"  File 


(One  Record  all  MOS,  one  record  nine  MOS  in  CV  Subpopulation) 
Field  Dictionary  Name  Size  Values  Total  Type  Comments 


1  Primary  MOS 

8 

1 

8 

C 

Record  Key 

2  A: Task  Number 

2 

17 

34 

N 

CV  Task  Field  Number 

3  A:Description 

500 

17 

3500 

C 

Behavior/Procedure 

Record  Size- 

3,542 

Number  of  Records- 

10 

Est.  File  Size- 

35,420 
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Table  50-2.2.  Project  A  Soldier  Sub-Population  "L V”  File 

(One  Record  all  MO S,  one  record  nine  MQS  in  LV  Subpopulation) 


Field 

Dictionary  Name 

S;ze  Values 

Total  Type 

Comments 

1 

Primary  MOS 

5 

1 

5 

C 

Record  Key 

2 

Population  Size 

6 

1 

6 

N 

Number  Holding  MOS 

3 

Males,  Females 

2 

2 

4 

N 

of  Population 

4 

Age  Croup 

2 

12 

24 

N 

in 

3 -Year  Croups 

5 

Years  of  Service 

2 

12 

24 

N 

in 

3-Year  Groups 

6 

Pay  Grade 

2 

14 

28 

N 

in 

each 

Pay  Crade 

7 

Racial  Group 

2 

6 

12 

N 

in 

each 

Race  Crou] 

8 

Ethnic  Group 

2 

22 

44 

N 

in 

each 

Category 

9 

Years  of  School 

2 

12 

24 

N 

in 

each 

Category 

10 

Educ .Certificate 

2 

16 

32 

N 

in 

each 

Category 

11 

College  Major 

2 

32 

64 

N 

in 

each 

Cacegory 

12 

Citizenship 

2 

5 

10 

N 

in 

each 

Category 

13 

Weight  Lift 

2 

7 

14 

N 

in 

each 

Category 

14 

Physical  Category 

2 

6 

12 

N 

in 

each 

Category 

15 

physical  Stamina 

2 

4 

8 

N 

in 

each 

Category 

16 

Upper  Extremities 

2 

3 

6 

N 

in 

each 

Category 

17 

Eower  Extremities 

2 

3 

6 

N 

in 

each 

Category 

18 

Hearing 

2 

4 

8 

N 

in 

each 

Category 

19 

Eyesight 

2 

2 

4 

N 

in 

each 

Category 

20 

£  Senses 

2 

3 

6 

N 

in 

each 

Category 

21 

Native  Language 

2 

2 

4 

C 

English/Ocher 

22 

Enlistment  Term 

2 

7 

14 

N 

in 

each 

Category 

23 

Army  Service  Type 

2 

5 

10 

N 

in 

each 

Category 

24 

AFTJT  Category 

2 

9 

18 

N 

in 

each 

Category 

25 

AFQT  Score 

2 

10 

20 

N 

in 

each 

Decile 

26 

Clerical  Aptitude  2 

10 

20 

N 

in 

each 

Decile 

27 

Combat  Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

28 

Elect. Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

29 

Fid. Arc. Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

30 

GenMa int . Ap  t i tude 

2 

10 

20 

N 

in 

each 

Decile 

31 

Gen . Tech . Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

32 

Mech.  Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

33 

Foods vc  Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

34 

PMOS  SQT  Score 

2 

10 

20 

N 

in 

each 

Decile 

35 

SurvComm . Ap  t i tude 

2 

10 

20 

N 

in 

each 

Decile 

36 

Tech. Aptitude 

2 

10 

20 

N 

in 

each 

Decile 

Project  A  Constructs  for  MANPRINT  Product  3 


37 

ArVerbal  Ability  2 

10 

20 

N 

% 

in 

each 

Decile 

38 

A:Numeric  Ability  2 

10 

20 

N 

% 

in 

each 

Decile 

39 

A.-Spatial  Ability  2 

10 

20 

N 

» 

in 

each 

Decile 

40 

A:Reasoning  Abil.  2 

10 

20 

N 

% 

in 

each 

Decile 

41 

A:Ment. Processing  2 

10 

20 

N 

% 

in 

each 

Decile 

42 

ArShorcTermMemory  2 

10 

20 

N 

» 

in 

each 

Decile 

43 

A: Percept. Speed  2 

10 

20 

N 

% 

in 

each 

Decile 

44 

A : Mech . Comprehen .  2 

10 

20 

N 

% 

in 

each 

Decile 

45 

A: Eye -Limb  Coord.  2 

10 

20 

N 

t 

in 

each 

Decile 

46 

A:MovementJudgnit .  2 

10 

20 

N 

* 

in 

each 

Decile 

Record  Size- 

819 

Number  of  Records- 

10 

Est . 

File  Size- 

8.190 
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Table  50-2.2.1.  Project  A  Soldier  Task  Performance  ”LV"  File 


(One  Record  all  MOS ,  one  record  nine  MOS  in  CV  Subpopulation) 
Field  Dictionary  Name  Si2e  Values  Total  Tvne  Comments 


1 

Primary  MOS 

8 

1 

8 

C 

Record  Key 

2 

A: Task- 1  Score 

2 

10 

20 

N 

%  in  each  Category 

18 

A:Task-18  Score 

2 

10 

20 

N 

%  in  each  Category 

19 

Last  Change 

Date 

8 

D 

YY/MM/DD  Format 

Record  Size- 

348 

Number  of  Records- 

10 

Est.  File  Size- 

3,480 

Table  50-2.2.2.  Project  A  Soldier  Task  Identification  "LV"  File 


(One  Record  all  MOS,  one  record  nine  MOS  in  CV  Subpopulation) 
Field  Dictionary  Name  Size  Values  Total  Type  Comments 


1  Primary  MOS 

2  A: Task  Number 

3  A: Description 

Record  Size- 
Number  of  Records- 
Est.  File  Size- 


8  1  8  C 

2  17  34  N 

500  17  3500  C 

3,542 

10 

35,420 


Record  Key 

CV  Task  Field  Number 

Behavior/Procedure 


Table  50*3.  MOS  Qualifications  File 


Held 

Dictionary  Name 

Size 

Values 

Total  Type 

Comments 

1 

Primary  MOS 

3 

1 

3 

C 

Record  Key 

2 

PULHES  Code 

6 

1 

6 

C 

AR 

Extract 

3 

Color  Vision 

1 

1 

1 

C 

AR 

Extract 

4 

Sec.  Clearance 

3 

1 

3 

C 

AR 

Extract 

5 

Aptitude  Codes 

2 

5 

10 

C 

AR 

Extract 

6 

Related  DOT  Codes 

7 

5 

35 

C 

AR 

Extract 

7 

Related  FCS  Codes 

7 

5 

35 

C 

AR 

Extract 

8 

"Must  Know"  List 

256 

8 

2048 

C 

AR 

Extract 

Record  Size- 

2141 

Number  of  Records- 

100 

Est.  File  Size- 

214,100 

Table  50-4.  MOS/ASI  Titles  and  Duties  File 


Field  Dictionary  Name  Size 

1  Primary  MOS  3 

2  MOS  Title  64 

3  AS I  Title  64 

4  Summary  Text  256 

5  Combat  Duties  128 


Record  Size- 
Number  of  Records- 
Est.  File  Size- 


Values  Total  Type  Comments 


1 

3 

C 

Record  Key 

1 

64 

C 

AR 

Extract 

1 

64 

C 

AR 

Extract 

1 

256 

C 

AR 

Extract 

8 

1024 

C 

AR 

Extract 

1411 

100 

141,100 
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Table  50-5.  DOT  Code  File 


Field  Dictionary  Name 

Size  Values 

Total  Tvoe 

Comments 

1  DOT  Code 

7 

1 

7  C 

Record  Key 

2  DOT  Title 

64 

1 

64  C 

DOT  Manual 

3  Primary  MOS 

3 

10 

30  C 

Applicability  Keys 

Record  Size- 

101 

Number  of  Records- 

200 

Est.  File  Size- 

20,200 

Table  50*6. 

FCS  Code  File 

Field  Dictionary  Name 

Size  Values 

Total  Type 

Comments 

1 

FCS  Code 

7 

l 

7  C 

Record  Key 

2 

FCS  Title 

64 

l 

64  C 

FCS  Manual 

3 

Primary  MOS 

3 

10 

30  C 

Applicability  Keys 

Record  Size- 

101 

Number  of  Records- 

200 

Est.  File  Size- 

20 , 200 

Table  50-'.  Soldier  Population  Design  Constraint  File 


lie 

Id  Dictionary  Name 

Size  Values 

Total  TvDe 

Comments 

1 

Constraint  Name 

32 

1 

32 

C 

Record  Key 

2 

Constraint  Levels 

32 

8 

256 

C 

Qualitative  Terms 

3 

Constraint  Values 

10 

8 

80 

N 

Quantitative  Terms 

4 

Level  Definition 

256 

8 

2048 

C 

Explanatory  Texts 

5 

Fill-Blank  Spec 

512 

1 

512 

C 

Model  Spec  Language 

Record  Size- 

2968 

Number  of  Records- 

100 

E  st 

.  File  Size- 

296,800 

i 


Table  50-8.  MANPR1NT  Product  1  Weapon  System/MOS 

Usage  File 


i 


Field  Dictionary  Name 

Size 

Values 

Total  Tvpe 

Comments 

1  Veapon  System 

64 

1 

64  C 

Record  Key 

2  Primary  MOS 

8 

8 

64  C 

Operators 

3  Primary  MOS 

8 

8 

64  C 

Maintenance 

4  Primary  MOS 

8 

8 

64  C 

Support  Personnel 

Record  Size- 

256 

Number  of  Records- 

100 

Est.  File  Size- 

25,600 

V-19 


f 


Table  50-9.  Project  A/ASVAB  Correlations  "CV"  File 


(One  record  all  MOS ,  one  record  nine  MOS  in  CV  population) 


Field  Dictionary  Name 

Size  Values 

Total  Tvoe 

Comments 

1  Primary  MOS 

8 

1 

8 

C 

Record  Key 

2  Matrix  Number 

3 

1 

3 

N 

Record  Key 

3  Matrix  Title 

64 

1 

64 

C 

Name  of  Test  Battery 

4  Row/Col  Titles 

12 

20 

240 

C 

Names  of  Measures 

5  400  Cell  Values 

4 

400 

1600 

N 

Format  0.00 

6  Research  Notes 

1024 

1 

1024 

C 

As  applicable 

Record  Sire- 

2939 

Number  of  Records- 

10 

Est.  File  Size- 

29,390 

Table  50-10.  ASVAB/Project  A  "LV"  Correlations  File 


(One  record  al)  MOS,  one  record  nine  MOS  in  LV  population) 


Held 

Dictionary  Name 

Size 

Values 

Total  Type 

Comments 

1 

Primary  MOS 

8 

1 

8 

C 

Record  Key 

1 

2 

Matrix  Number 

3 

1 

3 

N 

Record  Key 

3 

Matrix  Title 

64 

1 

64 

C 

Test  Battery  Names 

4 

Row/Col  Titles 

12 

20 

240 

C 

Names  of  Measures 

i 

5 

Cell  Values 

4 

400 

1600 

N 

Format  0.00 

( 

i 

6 

Research  Notes 

1024 

1 

1024 

C 

As  applicable 

I 

Record  Size- 

2939 

Number 

■  of  Records- 

10 

I 

Est.  File  Size- 

29,390 
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Table  50-11:  ASI  Code  File 


(One  Record  for  Each  ASI  Code) 


Field  Dictionary  Name 

1  ASI  Code 

2  ASI  Title 

3  Primary  MOS 

Record  Size- 
Number  of  Records- 
Est.  File  Size- 


Size 

Values  Total 

Type 

2 

1  2 

c 

64 

1  64 

c 

3 

10  30 

c 

96 

100 

9,600 

Comments 
Added  Skill  ID 
AR  Extract 
Applicability 
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Table  50*12:  Annual  Soldier  Accessions  File 


(One  Record  for  each  Training/Enlistment  HOS) 

Field  Dictionary  Name  Size  Values  T°t3-l.  IYP3  Comments 


l 

Training  M0S+FY  8 

1 

2 

Population  Size  6 

1 

3 

Males,  Females  2 

2 

4 

Age  Group  2 

12 

5 

Years  of  Service  2 

12 

6 

Pay  Grade  2 

14 

7 

Racial  Group  2 

6 

8 

Ethnic  Group  2 

22 

9 

Years  of  School  2 

12 

10 

Educ. Certificate  2 

16 

11 

College  Major  2 

32 

12 

Citizenship  2 

5 

13 

Weight  Lift  2 

7 

14 

Physical  Category  2 

6 

IS 

physical  Stanina  2 

A. 

16 

Upper  Extremities  2 

3 

17 

Lower  Extremities  2 

3 

18 

Hearing  2 

4 

19 

Eyesight  2 

2 

20 

£  Senses  2 

3 

21 

Native  Language  2 

2 

22 

Enlistment  Term  2 

7 

23 

Army  Service  Type  2 

5 

24 

AFOT  Category  2 

9 

25 

AFQT  Score  2 

10 

26 

Clerical  Aptitude  2 

10 

27 

Combat  Aptitude  2 

10 

28 

Elect. Aptitude  2 

10 

29 

Fid. Art. Aptitude  2 

10 

30 

GenMaint. Aptitude  2 

10 

31 

Gen. Tech. Aptitude  2 

10 

32 

Mech.  Aptitude  2 

10 

33 

FoodS vc  Aptitude  2 

10 

34 

PMOS  SQT  Score  2 

10 

35 

SurvComm . Aptitude  2 

10 

36 

Tech. Aptitude  2 

10 

8 

C 

Record  Key 

6 

N 

Number  Holding  M0S 

4 

N 

%  of  Population 

24 

N 

%  in  3 -Year  Groups 

24 

N 

%  in  3 -Year  Groups 

20 

N 

%  in  each  Pay  Grade 

12 

N 

%  in  each  Race  Group 

44 

N 

%  in  each  Category 

24 

N 

%  in  each  Category 

32 

N 

%  in  each  Category 

64 

N 

%  in  each  Category 

10 

N 

%  in  each  Category 

14 

N 

%  in  each  Category 

12 

N 

%  in  each  Category 

r% 

t  in  each  Category 

6 

N 

%  in  each  Category 

6 

N 

%  in  each  Category 

8 

N 

%  in  each  Category 

4 

N 

«  in  each  Category 

6 

N 

«  in  each  Category 

4 

C 

«  English/Other 

14 

N 

%  in  each  Category 

10 

N 

%  in  each  Category 

18 

N 

%  in  each  Category 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

20 

N 

%  in  each  Decile 

Record  Size- 
Number  of  Records- 
Est.  File  Size- 


622 

100 

622,000 


T 

t 
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